A
licenseNot graded
qualityC
maintenanceLuxury hotel intelligence and secure checkout handoff for AI travel agents.
1
Apache 2.0
Roomza Hotel Intelligence
Server Details
The room-level truth layer of hospitality. Verified scores for exact hotel rooms, not just hotels.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
12 toolsadd_special_requestAdd a special requestAInspect
Add a special request to one of your bookings (e.g. extra pillows, late checkout, anniversary celebration). Requires connecting your Roomza account.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | The special request to add | |
| booking_id | Yes | The booking ID to add the request to (get this from get_my_trips) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| message | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) indicate a non-destructive write operation. The description adds that the tool requires an authenticated Roomza account, which is relevant behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and examples, followed by a single prerequisite. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with 100% schema coverage and an output schema (not shown but indicated), the description is complete: it explains the action, gives examples, and states the account requirement. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds example values (extra pillows, late checkout) but does not add semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a special request to one of your bookings'. It provides concrete examples (extra pillows, late checkout, anniversary celebration) and distinguishes from sibling tools, which are all read-only or search tools. No other sibling adds anything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you have a booking and want to add a special request) and includes a prerequisite ('Requires connecting your Roomza account'). It does not explicitly state alternatives or when not to use, but given the tool's unique role among siblings, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ask_about_hotelAsk about a hotelARead-onlyIdempotentInspect
Ask a specific question about a hotel that standard data may not answer. Uses AI with web search to find the answer. Examples: 'Does this hotel have Eiffel Tower views?', 'Is there a rooftop bar?', 'How far is it from the airport?'. Try get_hotel first; use this only when that data doesn't answer the question.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_id | Yes | Hotel UUID (the URL slug also works) | |
| question | Yes | The specific question about the hotel |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| answer | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations by disclosing that the tool uses AI with web search and that it answers non-standard questions. This is valuable since openWorldHint alone does not explain the mechanism or typical use case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the core purpose, then provides concrete examples, and ends with precise routing guidance. Every sentence 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool does, the type of question it accepts, and the relationship to get_hotel. With an output schema present and annotations covering safety and open-world behavior, no critical information is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds value by providing concrete example questions that clarify what kind of 'question' is expected, helping the agent form valid inputs. While not strictly necessary, this enriches the parameter semantics beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('ask'), resource ('hotel'), and the distinctive scope: questions that standard data may not answer, answered via AI with web search. It is clearly differentiated from the get_hotel sibling, which is named explicitly as the alternative for standard data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing: 'Try get_hotel first; use this only when that data doesn't answer the question.' This clearly defines when to use this tool versus its closest sibling and leaves no ambiguity about the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hotelGet hotel detailsARead-onlyIdempotentInspect
Get full details for a hotel including: Roomza Truth summary, score breakdown, top strengths, hotel character (type, vibes, best-for), nearby landmarks with distances, neighborhood, awards, amenities, and review highlights from the open web. Use hotel name, slug, or UUID as the identifier. This is the FIRST call when the user names a specific hotel ('Wynn Las Vegas') — no search_hotels needed; the name resolves directly.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Hotel name, slug, or UUID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| hotel | Yes | null when the hotel was not found |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds behavior: name resolves directly without search, and explicitly lists what data is included (score breakdown, top strengths, hotel character, etc.). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, three sentences, front-loaded with the main purpose and then specifics. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, rich output schema, and annotations covering safety, the description covers scope, usage timing, and resolution behavior. It's complete for a read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter types (name, slug, UUID) which are already in the schema. It doesn't add deeper meaning like default behavior if not found, or examples. Schema coverage is 100%, so baseline is 3. The description adds no extra parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details for a hotel' and enumerates the specific data returned (Roomza Truth summary, score breakdown, hotel character, etc.). It uses a specific verb+resource structure and distinguishes itself from sibling tools by listing its unique scope. The phrase 'This is the FIRST call' further clarifies its primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this as the first call when a user names a hotel (e.g., 'Wynn Las Vegas') and that search_hotels is unnecessary. This provides clear when-to-use direction. While it doesn't mention other siblings like get_hotel_pricing, the directive to use this first strongly implies its role as the entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hotel_pricingGet room ratesARead-onlyIdempotentInspect
Get public room rates for a hotel (the hotel's own public rate; booking on Roomza never costs more). Pass check_in and check_out dates (YYYY-MM-DD) to get nightly from-prices per room type. Without dates, returns the hotel's typical nightly from-price. No booking links; to price and book an exact room, use secure_room.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| check_in | No | Check-in date in YYYY-MM-DD format (defaults to today) | |
| hotel_id | Yes | Hotel UUID (the URL slug also works) | |
| check_out | No | Check-out date in YYYY-MM-DD format (defaults to tomorrow) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| found | Yes | false when the hotel is unknown |
| nights | Yes | |
| checkIn | Yes | |
| checkOut | Yes | |
| currency | Yes | |
| hotelName | Yes | |
| roomTypes | Yes | Per-room-type from-prices when dates were given and live rates exist |
| typicalNightlyFrom | Yes | Hotel-level typical nightly from-price in dollars |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and idempotentHint=true, and the description adds behavioral context beyond that: rates are public, no booking links are returned, and date presence changes the output granularity. It also notes the rate is the hotel's own public rate with a guarantee that booking on Roomza never costs more. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly written sentences. The main action is front-loaded, the date behavior is explained immediately, and the sibling route is named in the closing sentence. Every sentence contributes a distinct piece of actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a low-complexity tool, full schema coverage, and an output schema present, the description is complete. It explains the primary behavior, the optional-date behavior, the booking alternative, and the absence of booking links. No critical gap remains for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with descriptions, including date format and defaults. The description adds extra meaning by explaining how the combination of check_in and check_out affects the result (nightly per-room-type prices versus typical nightly from-price). This goes beyond the schema baseline of 3, though the schema already carries substantial weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Get public room rates for a hotel." It clearly states the output is nightly from-prices per room type and explicitly distinguishes itself from secure_room by saying "No booking links." This differentiates it from sibling tools like get_hotel_rooms, show_rooms, and secure_room.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditions: pass check_in and check_out dates for nightly from-prices, or omit dates for typical nightly from-price. It also explicitly tells the agent when to use secure_room instead: "to price and book an exact room." This covers both when to use and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hotel_roomsList hotel roomsARead-onlyIdempotentInspect
List rooms for a hotel with individual Roomza scores, bed type, view, and floor. Pass room_number to look up a specific room.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_id | Yes | Hotel UUID from search_hotels/get_hotel (the URL slug also works) | |
| room_number | No | Look up a specific room by number, e.g. "434" |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Copy encouraging a booking + review to start this hotel's room record |
| count | Yes | |
| rooms | Yes | |
| bookUrl | Yes | Roomza booking link for this hotel; set only on the no-records fallback |
| roomTypes | Yes | Only populated when the hotel has no room records yet: bookable room types from live rates |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by naming the returned fields and the optional specific-room lookup behavior, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences fully capture the purpose and the optional lookup behavior. The most important information is front-loaded, and every phrase earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation backed by a rich schema, annotations, and an output schema, the description is adequate for correct invocation. It could be slightly more complete by clarifying pagination or explicitly contrasting with 'show_rooms', but those are not significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented with clear explanations, including the hotel_id source and a concrete room_number example. The description's 'Pass room_number to look up a specific room' mostly restates the schema, adding little new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('List rooms for a hotel') and the target resource, and it enumerates the returned attributes: Roomza scores, bed type, view, and floor. It is unambiguous, but it does not explicitly differentiate itself from the sibling tool 'show_rooms', so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: pass room_number to look up a specific room. However, it does not explain when to choose this tool over 'show_rooms' or other hotel-related tools, leaving alternative selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_preferencesYour preferencesARead-onlyIdempotentInspect
Get your saved room preferences, standing requests, and loyalty accounts on Roomza. Requires connecting your Roomza account.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| preferences | Yes | |
| travelCards | Yes | |
| loyaltyPrograms | Yes | |
| standingRequests | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds a behavioral precondition (requires account connection), which is valuable context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words. The first sentence captures the action and scope; the second adds a critical prerequisite. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema (not shown but exists), and annotations cover safety, the description is complete. It explains the purpose, scope, and prerequisite, which is sufficient for an agent to decide when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is trivially 100%. The baseline for 0-parameter tools is 4, and the description adds no conflicting or redundant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resources ('saved room preferences, standing requests, and loyalty accounts') on Roomza, which distinguishes it from sibling tools like add_special_request or get_hotel. The scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear and a prerequisite (account connection) is stated, but there is no explicit guidance on when to use this tool versus alternatives like add_special_request. An agent can infer the usage context from the name and description, but explicit when/when-not guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_tripsYour tripsARead-onlyIdempotentInspect
Look up your upcoming and past hotel bookings/trips on Roomza. Requires connecting your Roomza account.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| past | Yes | |
| count | Yes | |
| upcoming | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds value by disclosing the authentication requirement ('Requires connecting your Roomza account') and specifying the scope ('upcoming and past'). This is helpful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences (35 words) with no redundant or vague language. Every sentence provides essential information: the action and resource, and the prerequisite. It is highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no nested objects, has output schema), the description is complete. It explains the tool's purpose and a key requirement. The output schema is not shown but exists, so the description does not need to detail return values. The description is sufficient for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by default. The description does not need to add parameter semantics. Per the guidelines, baseline for 0 parameters is 4, and the description meets this standard without needing to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up your upcoming and past hotel bookings/trips on Roomza.' It uses a specific verb ('look up') and resource ('your upcoming and past hotel bookings/trips'), and the sibling tools list shows distinct alternatives like search_hotels or get_my_preferences, making this tool's unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires connecting your Roomza account'), which guides usage. However, it does not explicitly state when to use this tool versus siblings (e.g., when to use get_my_trips instead of search_hotels), nor does it provide exclusions. The usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nearbyGet nearby places and eventsARead-onlyIdempotentInspect
Get nearby places (restaurants, bars, attractions, parks) and upcoming events near a hotel. Optionally filter events to a travel window with start_date / end_date.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Travel end date YYYY-MM-DD -- filters events to this window | |
| hotel_id | Yes | Hotel UUID from search_hotels/get_hotel (the URL slug also works) | |
| start_date | No | Travel start date YYYY-MM-DD -- filters events to this window |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| events | Yes | |
| places | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful behavioral detail that date filtering applies only to events, but otherwise does not disclose additional runtime behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary purpose is front-loaded, the optional date-filtering behavior is stated succinctly, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only lookup tool with a full output schema, complete parameter documentation, and readOnly/idempotent annotations, the description covers everything an agent needs to invoke it correctly. It even clarifies that the optional date window applies only to events.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents hotel_id, start_date, and end_date. The description adds a brief restatement that dates filter events to a travel window, which is helpful but not necessary given the schema already explains each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('nearby places and upcoming events near a hotel'), and enumerates the place categories. It is immediately distinguishable from sibling tools like get_hotel or search_hotels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals this tool is for place/event discovery around a hotel and mentions optional date filtering, providing clear context for when to use it. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_reviewsGet guest reviewsARead-onlyIdempotentInspect
Get verified guest reviews for a hotel, including comments and insider tips. Pass room_number to get reviews for a specific room.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of reviews (default 5) | |
| hotel_id | Yes | Hotel UUID (the URL slug also works) | |
| room_number | No | Filter reviews to a specific room number, e.g. "434" |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Set when no reviews are returned, e.g. unknown room |
| count | Yes | |
| reviews | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate that this is a safe read. The description adds useful context about 'verified' reviews and 'comments and insider tips,' but it does not disclose ordering, pagination, or response shape. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the main action front-loaded and a conditional usage tip at the end. It avoids filler, does not restate the schema, and every phrase adds either content scope or invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only review lookup, the description, annotations, full parameter schema, and existing output schema collectively provide enough information for an agent to invoke the tool correctly. The only minor omission is that the description does not explicitly say 'recent,' which is present only in the tool name and title.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so hotel_id, limit, and room_number are already documented in the schema. The description's mention of room_number adds no new semantic meaning beyond the schema's 'Filter reviews to a specific room number.' Baseline 3 applies because the structured schema carries most of the parameter-documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Get verified guest reviews') and a clear resource ('reviews for a hotel'), and it adds the included content ('comments and insider tips'). This naturally distinguishes it from sibling tools that handle pricing, rooms, trips, and searches, none of which target guest reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the review-lookup context clear and gives a concrete usage condition ('Pass room_number to get reviews for a specific room'). It does not explicitly compare against alternatives like ask_about_hotel or state when not to use this tool, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hotelsSearch hotelsARead-onlyIdempotentInspect
DISCOVERY ONLY: search Roomza's hotel database by city, keyword, or natural language query when the user has NOT named a specific hotel. Understands hotel types (boutique, resort, luxury), vibes (romantic, trendy, quiet), traveler types (couples, families, solo), neighborhoods, and nearby landmarks. Example queries: 'boutique hotels in SoHo', 'romantic resort near the Eiffel Tower', 'pet-friendly hotel in Seattle'. Renders for the user as a full map with a multi-hotel list (so do not repeat the list in prose). NEVER use this when the user names one specific hotel (e.g. 'Wynn Las Vegas'): the map of many hotels is wrong for that. Call get_hotel with the hotel name instead, then get_hotel_rooms and show_rooms.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Narrow results to a specific city | |
| limit | No | Max results (default 10) | |
| query | Yes | Hotel name, city, or keyword |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Search note, e.g. a nearby-city fallback explanation |
| count | Yes | Number of hotels returned |
| hotels | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is covered. The description adds valuable behavioral context by noting that the tool renders as a map with a multi-hotel list and instructing not to repeat the list in prose, which goes beyond annotations. It also mentions the scope of search capabilities, but doesn't detail any potential rate limits or latency, which are generally expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is information-dense but well-structured. It front-loads the purpose and includes specific usage guidance, examples, and exclusion criteria. Each sentence serves a purpose, though it could be slightly condensed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and strong annotations, the description is complete. It covers purpose, usage scope, exclusion criteria, and rendering behavior. For a search tool with a clear query input and output schema, this is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already documents each parameter. The description adds meaning by explaining that the query parameter can be a natural language query and providing example query patterns, which enriches the query semantics beyond the schema's basic description. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'DISCOVERY ONLY' and states that it searches Roomza's hotel database by city, keyword, or natural language query, which is a specific verb+resource+scoping. It distinguishes itself from sibling tools by explicitly saying it is for when the user has NOT named a specific hotel, contrasting with get_hotel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (user has NOT named a specific hotel) and when not to use (when user names one specific hotel like 'Wynn Las Vegas'), and even directs the agent to alternative tools (get_hotel, then get_hotel_rooms and show_rooms) in that case. This is clear guidance on usage and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secure_roomPrice and lock a roomAInspect
Price and lock an exact room for specific dates with Room Lock. Returns the live price, cancellation policy, and a secure booking link with the room preselected. Requires connecting your Roomza account.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| guests | No | Guest count (default 2) | |
| room_id | Yes | Room UUID (from show_rooms or get_hotel_rooms) | |
| check_in | Yes | Check-in date, YYYY-MM-DD | |
| check_out | Yes | Check-out date, YYYY-MM-DD |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | false = the request could not be quoted; see message |
| guests | Yes | |
| nights | Yes | |
| roomId | Yes | |
| checkIn | Yes | |
| hotelId | Yes | |
| message | Yes | Set when ok is false |
| bookable | Yes | true when a live bookable rate was found |
| checkOut | Yes | |
| currency | Yes | |
| rateName | Yes | |
| hotelName | Yes | |
| bookingUrl | Yes | Secure checkout link with the room preselected; payment happens only there |
| dueAtHotel | Yes | Additional amount due at the hotel, dollars |
| publicRate | Yes | Hotel's public rate in dollars, for comparison |
| roomNumber | Yes | |
| totalToday | Yes | Total charged today in dollars |
| trackRecord | Yes | Hotel's room-request honor track record |
| cancellation | Yes | |
| indicativeOnly | Yes | true when the price is from public listings, not bookable |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal behavioral info (readOnlyHint=false, destructiveHint=false, etc.), so the description carries the burden. It discloses that the tool performs a locking operation and returns specific data. It does not explain the nature of the lock (temporary? charged?), potential side effects, or error conditions. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: action, result, prerequisite. No redundant words. Core information is front-loaded ('Price and lock an exact room'). Excellent use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers return values (price, cancellation, booking link) and a prerequisite. It does not address edge cases like room unavailability or lock duration, but the output schema likely fills some gaps. Very good overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no specific parameter-level meaning beyond the schema (e.g., 'specific dates' is vague). Baseline 3 is appropriate since the description does not compensate or elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Price and lock') and resource ('exact room for specific dates'), clearly distinguishing it from sibling tools like get_hotel_pricing (pricing only) or show_rooms (listing). It states the exact outcome: returns live price, cancellation policy, and a secure booking link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case (locking a room after selection) and notes a prerequisite ('Requires connecting your Roomza account'). However, it does not explicitly state when to use this tool versus alternatives like get_hotel_pricing or show_rooms, or mention what happens if the room is unavailable. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_roomsShow roomsARead-onlyIdempotentInspect
REQUIRED whenever you present rooms. Whenever you are about to mention, recommend, or describe one or more specific rooms to the user, you MUST call this tool with those room UUIDs INSTEAD of writing the rooms in text. This is mandatory even when there is only ONE matching room — show it as a single hero card, never describe a lone room in prose. Call this BEFORE writing any prose about the rooms; the cards must appear first, then a brief summary. Pass room UUIDs (from get_hotel_rooms or search results) in ranked order, best first, 1 to 8 rooms. ALWAYS pass check_in and check_out when you know the user's dates: card prices are then for those exact dates. Without dates, cards show a typical from-price that can differ a lot from any specific dates. Each card shows photo, Roomza score, view, bed, and price. NEVER ask the user whether they want to see cards or images — just call this tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| check_in | No | Check-in date YYYY-MM-DD. Pass whenever the user's dates are known so card prices match those dates. | |
| room_ids | Yes | Room UUIDs to display, in ranked order (best first). 1-8 rooms. | |
| check_out | No | Check-out date YYYY-MM-DD. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rooms | Yes |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety. It adds valuable behavioral context: the tool must be called before writing prose, cards appear first, and it shows specific content (photo, score, view, bed, price). No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the most critical rule front-loaded ('REQUIRED'). It is somewhat verbose but every sentence serves a purpose. Could be slightly more concise, but overall the structure effectively communicates mandatory usage and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, output schema, and annotations, the description is exceptionally complete. It covers all aspects: mandatory invocation, ordering, date handling, what each card shows, and the prohibition on asking users. No gaps remain for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds extra meaning: room_ids must be in ranked order, best first, 1-8 rooms; explains the difference between passing dates (exact prices) vs no dates (typical from-price). This significantly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to display rooms as cards instead of describing them in text. It specifies the verb (show) and resource (rooms), and differentiates from sibling tools like get_hotel_rooms by mandating its use when presenting rooms to the user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'REQUIRED whenever you present rooms' and 'whenever you are about to mention, recommend, or describe one or more specific rooms'. It also gives when-not-to-use guidance: 'NEVER ask the user whether they want to see cards'. It includes ordering and date handling instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
- Changed
ask_about_hotel1 field changed- changed
Input schema / properties / hotel_id / descriptionPrevious value: -"Hotel UUID"New value: +"Hotel UUID (the URL slug also works)"
- Changed
get_hotel_pricing1 field changed- changed
Input schema / properties / hotel_id / descriptionPrevious value: -"Hotel UUID"New value: +"Hotel UUID (the URL slug also works)"
- Changed
get_hotel_rooms1 field changed- changed
Input schema / properties / hotel_id / descriptionPrevious value: -"Hotel UUID (get this from search_hotels or get_hotel)"New value: +"Hotel UUID from search_hotels/get_hotel (the URL slug also works)"
- Changed
get_nearby1 field changed- changed
Input schema / properties / hotel_id / descriptionPrevious value: -"Hotel UUID (get this from search_hotels or get_hotel)"New value: +"Hotel UUID from search_hotels/get_hotel (the URL slug also works)"
- Changed
get_recent_reviews1 field changed- changed
Input schema / properties / hotel_id / descriptionPrevious value: -"Hotel UUID"New value: +"Hotel UUID (the URL slug also works)"
1 tool update
- Changed
get_hotel_rooms4 fields changed- added
Output schema / properties / bookUrlAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Roomza booking link for this hotel; set only on the no-records fallback" +} - added
Output schema / properties / noteAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Copy encouraging a booking + review to start this hotel's room record" +} - added
Output schema / properties / roomTypesAdded value: +{ + "description": "Only populated when the hotel has no room records yet: bookable room types from live rates", + "items": { + "additionalProperties": false, + "properties": { + "fromNightly": { + "description": "Typical nightly from-price in USD from the hotel's public rates", + "type": "number" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "fromNightly" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "count", - "rooms" -]New value: +[ + "count", + "rooms", + "roomTypes", + "bookUrl", + "note" +]
2 tool updates
- Changed
search_hotels7 fields changed- added
Output schema / properties / hotels / items / properties / fromNightlyAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Cached nightly from-price in USD; null when uncovered" +} - added
Output schema / properties / hotels / items / properties / latAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / hotels / items / properties / lngAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / hotels / items / properties / photoUrlAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / hotels / items / properties / roomCountAdded value: +{ + "description": "Rooms tracked on Roomza for this hotel", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - added
Output schema / properties / hotels / items / properties / roomsWithRecordsAdded value: +{ + "description": "Tracked rooms with at least one verified review", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - changed
Output schema / properties / hotels / items / requiredPrevious value: -[ - "id", - "name", - "city", - "state", - "country", - "url", - "score", - "reviewCount", - "hotelType", - "vibes", - "neighborhood" -]New value: +[ + "id", + "name", + "city", + "state", + "country", + "url", + "score", + "reviewCount", + "hotelType", + "vibes", + "neighborhood", + "lat", + "lng", + "photoUrl", + "roomCount", + "roomsWithRecords", + "fromNightly" +]
- Changed
show_rooms2 fields changed- added
Output schema / properties / rooms / items / properties / photoSourceAdded value: +{ + "anyOf": [ + { + "enum": [ + "room", + "hotel" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Whether photoUrl shows the actual room or is a hotel-level fallback" +} - changed
Output schema / properties / rooms / items / requiredPrevious value: -[ - "id", - "hotelId", - "hotelName", - "location", - "roomLabel", - "roomNumber", - "floor", - "score", - "reviewCount", - "pricePerNight", - "priceNote", - "currency", - "photoUrl", - "view", - "bedType", - "sqFt", - "blurb", - "url" -]New value: +[ + "id", + "hotelId", + "hotelName", + "location", + "roomLabel", + "roomNumber", + "floor", + "score", + "reviewCount", + "pricePerNight", + "priceNote", + "currency", + "photoUrl", + "photoSource", + "view", + "bedType", + "sqFt", + "blurb", + "url" +]
5 tool updates
- Added
add_special_request - Added
get_my_preferences - Added
get_my_trips - Added
secure_room - Changed
show_rooms5 fields changed- added
Input schema / properties / check_inAdded value: +{ + "description": "Check-in date YYYY-MM-DD. Pass whenever the user's dates are known so card prices match those dates.", + "type": "string" +} - added
Input schema / properties / check_outAdded value: +{ + "description": "Check-out date YYYY-MM-DD.", + "type": "string" +} - added
Output schema / properties / rooms / items / properties / priceNoteAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Shown in the price slot when pricePerNight is null, e.g. a prompt to provide dates" +} - added
Output schema / properties / rooms / items / properties / pricePerNight / descriptionAdded value: +"Nightly price for the requested dates; null when no dates were given or no live rate exists" - changed
Output schema / properties / rooms / items / requiredPrevious value: -[ - "id", - "hotelId", - "hotelName", - "location", - "roomLabel", - "roomNumber", - "floor", - "score", - "reviewCount", - "pricePerNight", - "currency", - "photoUrl", - "view", - "bedType", - "sqFt", - "blurb", - "url" -]New value: +[ + "id", + "hotelId", + "hotelName", + "location", + "roomLabel", + "roomNumber", + "floor", + "score", + "reviewCount", + "pricePerNight", + "priceNote", + "currency", + "photoUrl", + "view", + "bedType", + "sqFt", + "blurb", + "url" +]
8 tool updates
- Changed
ask_about_hotel1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "answer": { + "type": "string" + } + }, + "required": [ + "answer" + ], + "type": "object" +}
- Changed
get_hotel1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "found": { + "type": "boolean" + }, + "hotel": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "amenities": { + "items": { + "type": "string" + }, + "type": "array" + }, + "awards": { + "items": { + "type": "string" + }, + "type": "array" + }, + "bestFor": { + "items": { + "type": "string" + }, + "type": "array" + }, + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "googleRating": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "googleReviewCount": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "hotelType": { + "items": { + "type": "string" + }, + "type": "array" + }, + "id": { + "type": "string" + }, + "knownViews": { + "items": { + "type": "string" + }, + "type": "array" + }, + "landmarks": { + "items": { + "additionalProperties": false, + "properties": { + "distanceMi": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "distanceMi" + ], + "type": "object" + }, + "type": "array" + }, + "name": { + "type": "string" + }, + "neighborhood": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reviewCount": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "roomzaTruth": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Roomza score 0-100; null when unreviewed" + }, + "scoreBreakdown": { + "items": { + "additionalProperties": false, + "properties": { + "label": { + "type": "string" + }, + "score": { + "type": "number" + } + }, + "required": [ + "label", + "score" + ], + "type": "object" + }, + "type": "array" + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "starRating": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "state": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "topStrengths": { + "items": { + "additionalProperties": false, + "properties": { + "label": { + "type": "string" + }, + "score": { + "type": "number" + } + }, + "required": [ + "label", + "score" + ], + "type": "object" + }, + "type": "array" + }, + "uniqueFeatures": { + "items": { + "type": "string" + }, + "type": "array" + }, + "url": { + "type": "string" + }, + "verificationStatus": { + "type": "string" + }, + "vibes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "zip": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "slug", + "name", + "url", + "address", + "city", + "state", + "zip", + "starRating", + "verificationStatus", + "score", + "reviewCount", + "scoreBreakdown", + "topStrengths", + "googleRating", + "googleReviewCount", + "amenities", + "hotelType", + "vibes", + "bestFor", + "neighborhood", + "awards", + "knownViews", + "uniqueFeatures", + "landmarks", + "roomzaTruth" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "null when the hotel was not found" + } + }, + "required": [ + "found", + "hotel" + ], + "type": "object" +}
- Changed
get_hotel_pricing1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "checkIn": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "checkOut": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "currency": { + "type": "string" + }, + "found": { + "description": "false when the hotel is unknown", + "type": "boolean" + }, + "hotelName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "nights": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "note": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "roomTypes": { + "description": "Per-room-type from-prices when dates were given and live rates exist", + "items": { + "additionalProperties": false, + "properties": { + "fromNightly": { + "description": "Nightly from-price in whole dollars, hotel's own public rate", + "type": "number" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "fromNightly" + ], + "type": "object" + }, + "type": "array" + }, + "typicalNightlyFrom": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Hotel-level typical nightly from-price in dollars" + } + }, + "required": [ + "found", + "hotelName", + "currency", + "checkIn", + "checkOut", + "nights", + "roomTypes", + "typicalNightlyFrom", + "note" + ], + "type": "object" +}
- Changed
get_hotel_rooms1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "rooms": { + "items": { + "additionalProperties": false, + "properties": { + "adaAccessible": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "adaFeatures": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "balcony": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "bathtub": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "null = unknown; false = confirmed absent" + }, + "bedType": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "floor": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "id": { + "description": "Room UUID — pass to show_rooms or secure_room", + "type": "string" + }, + "microwave": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "miniFridge": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "reviewCount": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "roomNumber": { + "type": "string" + }, + "roomTypeName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Roomza room score 0-100" + }, + "sqFt": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "view": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "roomNumber", + "floor", + "roomTypeName", + "bedType", + "view", + "sqFt", + "bathtub", + "balcony", + "adaAccessible", + "miniFridge", + "microwave", + "adaFeatures", + "score", + "reviewCount", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "count", + "rooms" + ], + "type": "object" +}
- Changed
get_nearby1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "events": { + "items": { + "additionalProperties": false, + "properties": { + "date": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "ticketLink": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "title": { + "type": "string" + }, + "venueName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "when": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "title", + "date", + "when", + "venueName", + "ticketLink" + ], + "type": "object" + }, + "type": "array" + }, + "found": { + "type": "boolean" + }, + "places": { + "items": { + "additionalProperties": false, + "properties": { + "address": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "category": { + "type": "string" + }, + "name": { + "type": "string" + }, + "priceLevel": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "rating": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "name", + "category", + "rating", + "priceLevel", + "address" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "found", + "places", + "events" + ], + "type": "object" +}
- Changed
get_recent_reviews1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "note": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Set when no reviews are returned, e.g. unknown room" + }, + "reviews": { + "items": { + "additionalProperties": false, + "properties": { + "comment": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "guestDisplayName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "insiderTip": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "roomId": { + "type": "string" + }, + "roomNumber": { + "type": "string" + }, + "roomUrl": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Overall score 0-100" + }, + "stayMonth": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "guestDisplayName", + "stayMonth", + "roomId", + "roomNumber", + "roomUrl", + "score", + "comment", + "insiderTip" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "count", + "note", + "reviews" + ], + "type": "object" +}
- Changed
search_hotels1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "count": { + "description": "Number of hotels returned", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "hotels": { + "items": { + "additionalProperties": false, + "properties": { + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "country": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "hotelType": { + "items": { + "type": "string" + }, + "type": "array" + }, + "id": { + "description": "Hotel UUID — pass to get_hotel_rooms, get_hotel_pricing, get_nearby, ask_about_hotel", + "type": "string" + }, + "name": { + "type": "string" + }, + "neighborhood": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reviewCount": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Roomza score 0-100; null when unreviewed" + }, + "state": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "url": { + "description": "Canonical Roomza hotel page", + "type": "string" + }, + "vibes": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "city", + "state", + "country", + "url", + "score", + "reviewCount", + "hotelType", + "vibes", + "neighborhood" + ], + "type": "object" + }, + "type": "array" + }, + "note": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Search note, e.g. a nearby-city fallback explanation" + } + }, + "required": [ + "count", + "note", + "hotels" + ], + "type": "object" +}
- Changed
show_rooms1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "rooms": { + "items": { + "additionalProperties": false, + "properties": { + "bedType": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "blurb": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "currency": { + "type": "string" + }, + "floor": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "hotelId": { + "type": "string" + }, + "hotelName": { + "type": "string" + }, + "id": { + "type": "string" + }, + "location": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "photoUrl": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "pricePerNight": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "reviewCount": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "roomLabel": { + "type": "string" + }, + "roomNumber": { + "type": "string" + }, + "score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "sqFt": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "url": { + "type": "string" + }, + "view": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "hotelId", + "hotelName", + "location", + "roomLabel", + "roomNumber", + "floor", + "score", + "reviewCount", + "pricePerNight", + "currency", + "photoUrl", + "view", + "bedType", + "sqFt", + "blurb", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "rooms" + ], + "type": "object" +}
8 tool updates
- First observed
ask_about_hotel - First observed
get_hotel - First observed
get_hotel_pricing - First observed
get_hotel_rooms - First observed
get_nearby - First observed
get_recent_reviews - First observed
search_hotels - First observed
show_rooms
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Dated, sourced trust receipts on local businesses. Attests facts; never approves the booking.
Live Booking.com hotel prices, plus per-country pricing for rate-parity monitoring.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
Related MCP Servers
Dida Hotel MCPofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.81MIT- AlicenseNot gradedqualityBmaintenanceBook hotels worldwide — search, price, prebook & book across 249 countries. 65 tools for hotel search, flights, loyalty, analytics. Zero API keys needed. at best prices for hotels 3 M+ property221MIT
- FlicenseNot gradedqualityDmaintenanceThe owner-verified local business data + service & menu-price layer for AI agents. Owner-authored business profiles where every response carries provenance — verification level, completeness score, freshness timestamps, and upstream sources. * Search & profiles — find businesses by name, category, city, or geo-radius; full profiles with contacts, hours, media, ratings. * Price layer-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.4/5.0
Disambiguation5/5
Each tool has a clear, distinct purpose: searching, retrieving details, pricing, rooms, reviews, nearby places, user-specific actions (preferences, trips), booking, and presentation. The overlap between get_hotel and ask_about_hotel is intentional and clearly differentiated (ask is for supplementary questions), and get_hotel_rooms vs show_rooms are also distinct (list vs present).
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: get_hotel, get_hotel_pricing, get_hotel_rooms, get_my_preferences, get_my_trips, get_nearby, get_recent_reviews, search_hotels, secure_room, show_rooms, add_special_request, ask_about_hotel. The only minor variation is 'ask_about_hotel' but it's still verb-based and follows the same structure.
Tool Count5/5
Twelve tools is well within the optimal range for a domain of this scope. The toolset covers the core lifecycle (search, view, price, book, add request, view trips) plus supporting functions (reviews, nearby, user preferences, presentation). No redundant or superfluous tools exist.
Completeness4/5
The toolset covers the primary hotel intelligence and booking workflow thoroughly: search, detail, pricing, rooms, booking, special requests, and user data. Slight gap: no explicit cancellation or booking modification tool, but given the server's focus on intelligence and presentation, this is a minor omission that agents can work around.