Consumer hotel search, live rates, booking, order management, and payment via TourMind.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 10 of 10 tools scored.
Most tools have clear, distinct purposes covering search, details, rates, booking, payment, and cancellation. Some pairwise overlap exists (e.g., query_room_rates vs. check_room_availability, search_hotels vs. search_location), but descriptions clarify the intended use.
All tool names follow a consistent verb_noun pattern with underscores (cancel_booking, create_booking, query_booking, search_hotels). The verbs are uniform and predictable, making the set easy to navigate.
With 10 tools, the server is well-scoped for a hotel booking workflow. Each tool covers a necessary step from search to payment to cancellation, and none feels redundant.
Core lifecycle coverage is solid: search, detail, rates, booking, payment, query, cancel. A clear gap is the absence of an update/modify booking tool, which is a common need. The unrelated check_skill_update is a minor distraction.
cancel_bookingCancel BookingACancel 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.
check_room_availabilityCheck Room AvailabilityARecheck the selected rate code, price, and inventory before booking.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adults per 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 | |
| check_in_date | No | Check-in date in YYYY-MM-DD format | |
| 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, openWorldHint, and idempotentHint, so the tool is understood as a safe, read-only check. The description adds that it rechecks the selected rate code, price, and inventory, which is useful but not a rich behavioral disclosure. 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?
Description is a single sentence that immediately states the action and purpose. No wasted words and it is front-loaded with the verb and key objects.
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 that an output schema exists, the description need not detail return values. The core purpose is clear and consistent with the parameter list and sibling tool set. A short note about the possibility of changes (consistent with openWorldHint) would be helpful, but the description is adequate for a simple pre-booking check.
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% with each parameter having a description. The tool description adds no parameter-specific meaning beyond the schema, 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 uses the specific verb 'recheck' with clear resources ('rate code, price, and inventory') and temporal context ('before booking'). This clearly distinguishes the tool from siblings like query_room_rates (which likely provides initial rates) and create_booking (which finalizes the reservation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before booking' provides clear context for when this tool should be invoked. It implies it follows rate selection and precedes booking, but it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_skill_updateCheck Skill UpdateACheck 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_bookingCreate BookingACreate a hotel booking from a verified rate. A valid user_key is required.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | Yes | Number of adults per 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 | |
| total_price | Yes | Verified total booking price | |
| check_in_date | Yes | Check-in date in YYYY-MM-DD format | |
| 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 carry destructiveHint=true, so the agent already knows it's a write operation. The description adds meaningful context beyond that: a valid user_key is required for authentication, and the booking must originate from a verified rate, implying a safety check. It does not contradict annotations and adds useful behavioral prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action, and includes two essential conditions (verified rate, user_key) without any verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 params, 10 required) and the existence of an output schema, the description covers the key operational prerequisites: verified rate and user_key. It could be more explicit about separation from payment (sibling pay_order), but the current text is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter description coverage, including specifics like 'Verified rate code returned by check_room_availability' for rate_code. The description reinforces the verified-rate context but does not add substantial new information about individual parameters. 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 the specific verb 'Create' with the resource 'hotel booking', and adds the key qualifier 'from a verified rate', which distinguishes it from siblings like cancel_booking, query_booking, and check_room_availability. This clearly states what the tool does.
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 should be used when creating a booking from a verified rate, implying a prior call to check_room_availability. However, it does not explicitly exclude alternatives like pay_order or mention when not to use it. The requirement of a valid user_key is a useful usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hotel_detailGet Hotel DetailAGet 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.
pay_orderPay OrderACreate 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_bookingQuery BookingAQuery 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.
query_room_ratesQuery Room RatesAGet live room types and rate products for a hotel and stay.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adults per room | |
| hotel_id | Yes | TourMind hotel identifier | |
| user_key | No | Optional TourMind user key for authenticated ToC access | |
| room_count | No | Number of rooms | |
| check_in_date | No | Check-in date in YYYY-MM-DD format | |
| 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, openWorldHint, and idempotentHint, covering the safety profile. The description adds 'live' indicating real-time data fetching, which is useful context. It does not disclose rate limits or auth requirements, but the param description for user_key covers authentication. Given annotation coverage, a 3 is appropriate.
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 sentence, front-loaded with action verb, no unnecessary words. It could include more detail without bloat, but remains appropriately concise and easily parseable. Slightly above baseline due to efficiency.
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 an output schema present and all parameters documented in the input schema, the description provides sufficient context for a simple query tool. It omits details like rate product structure, but these are covered by the output schema. The description is complete enough for an agent to select and 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 descriptions for all 6 parameters. The description does not add extra semantics beyond the schema, but it reinforces that hotel_id and dates define the 'stay'. Baseline 3 is justified because the schema already documents parameters effectively.
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?
Description uses specific verb 'Get' with resource 'live room types and rate products' and scope 'for a hotel and stay'. It clearly distinguishes from sibling 'check_room_availability' by focusing on rates/products rather than availability, but does not explicitly name the alternative.
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 (when you need room types and rates for a hotel stay) but does not specify when not to use it or mention alternatives like check_room_availability. No explicit exclusions are stated, leaving usage guidance implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hotelsSearch HotelsASearch 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 per room | |
| keyword | No | Hotel name or location keyword when region_id and coordinates are unavailable | |
| 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 | |
| lowest_price | No | Minimum total price filter | |
| check_in_date | No | Check-in date in YYYY-MM-DD format | |
| 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, providing the safety profile. The description adds no additional behavioral details such as pagination, result ordering, or interaction between search modes, but it does not contradict the annotations. Since the bar is lower with annotations, a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and lists the main search modes with no fluff. It is concise and well-structured, containing only necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 14 optional parameters and three search modes, the description provides a minimum viable overview but does not clarify whether modes can be combined, what happens when no location criteria are supplied, or how price/date filters interact. The rich schema and annotations mitigate this gap, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 14 parameters already have meaningful descriptions. The description maps the search modes to relevant parameters (region_id, latitude/longitude/radius_km, keyword) but does not add beyond the schema. Baseline 3 is correct because the schema carries the parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'search' for 'hotels' and specifies three distinct input modes: region, coordinates+radius, and fuzzy keyword. This distinguishes it from sibling tools like search_location and get_hotel_detail, making the scope 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 implies usage when the user has region, coordinates, or keyword inputs, but it does not explicitly state when to use this tool over alternatives such as search_location or query_room_rates. No exclusions or alternative recommendations are provided, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_locationSearch LocationAResolve 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
