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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 82 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A4.2/5.0
Scored across 12 tools
Disambiguation4/5
Most tools have clearly distinct purposes, and the descriptions explicitly route between discovery (search_hotels), named-hotel lookup (get_hotel), and fallback questions (ask_about_hotel). There is some overlap because get_hotel already includes nearby landmarks and review highlights while get_nearby and get_recent_reviews exist separately, and get_hotel_rooms versus show_rooms requires understanding data retrieval vs rendering.
Naming Consistency4/5
All names use snake_case and generally follow an action_resource pattern, with get_ being the dominant verb. Minor deviations include add_special_request, ask_about_hotel, search_hotels, secure_room, and show_rooms, but the set remains readable and predictable.
Tool Count5/5
Twelve tools is well within a reasonable range for a hotel intelligence and booking-support server. Each tool maps to a distinct stage: discovery, hotel detail, rooms, pricing, reviews, nearby context, account data, special requests, securing a room, and rendering room cards.
Completeness4/5
The surface covers the main workflow from hotel search through details, room selection, pricing, reviews, nearby context, account trips/preferences, special requests, and securing a room. The main gaps are booking modification/cancellation operations and direct booking finalization, though secure_room’s booking link and get_my_trips partially mitigate this.
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.
| 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
| 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_id | Yes | Hotel UUID (the URL slug also works) | |
| question | Yes | The specific question about the hotel |
Output 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.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Hotel name, slug, or UUID |
Output 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). 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.
| 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
| 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.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely non-redundant behavior: results are 'from' prices only, there are no booking links, and omitting dates silently shifts to a different data shape. It does not discuss caching, rate limits or freshness of pricing, which would have pushed it to a 5.
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 tight sentences: purpose, mode selection, exclusion plus alternative. The most decision-relevant information (what it returns and when the parameters change that) is front-loaded with no filler.
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?
An output schema exists, so return values need no prose; the description nonetheless conveys the output shape (nightly from-prices per room type) and the degraded no-dates mode. For a 3-parameter read-only tool this is complete enough to invoke correctly on the first try.
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 coverage is 100%, so the baseline is 3, but the description adds real semantic meaning: the date pair changes the granularity from a single typical price to per-room-type nightly from-prices. It also repeats the YYYY-MM-DD format and the no-dates fallback, which the schema only vaguely hints at ('defaults to today/tomorrow').
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?
States a specific verb and resource (get public room rates for a hotel) and immediately scopes it as the hotel's own public rate rather than a negotiated or exact-room rate. This distinguishes it from siblings like get_hotel_rooms, show_rooms and secure_room without needing the schema.
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 routes two modes: with check_in/check_out you get nightly from-prices per room type, without dates you get a typical from-price. It also names the alternative for exact pricing and booking (secure_room) and states the exclusion (no booking links).
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.
| 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
| 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| past | Yes | |
| count | Yes | |
| upcoming | Yes |
TDQS
A3.7/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, covering safety. The description adds value by disclosing the account connection requirement and the scope (upcoming and past bookings), which are behavioral prerequisites not captured in annotations. This exceeds the baseline but does not elaborate on return format or pagination, which is partially covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The core action is front-loaded, and the additional prerequisite is stated compactly. Every word earns its place.
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 tool with no parameters and an output schema present, the description covers the essential context: what it returns (trips/bookings) and a prerequisite (account connection). It does not describe return fields, but the output schema handles that. Unclear edge cases like what happens without a connection are minor for a tool of this simplicity.
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 baseline for parameter semantics is 4. The description correctly omits parameter explanations since none exist. Schema coverage is technically 100% (vacuously), so there is no gap to compensate for.
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 states a clear verb and resource: 'Look up your upcoming and past hotel bookings/trips on Roomza.' This distinguishes it from sibling tools like search_hotels or get_hotel by focusing on the user's own bookings rather than general hotel information. However, it does not explicitly contrast with a sibling, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a prerequisite ('Requires connecting your Roomza account') but no guidance on when to use this tool versus alternatives such as get_hotel or secure_room. It does not state explicit conditions or exclusions, leaving usage context largely to inference. This is a significant gap.
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.
| 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
| 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.
| 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
| 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.
| 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 | |
| check_in | No | Check-in date YYYY-MM-DD, when the user gave dates | |
| check_out | No | Check-out date YYYY-MM-DD |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Search note, e.g. a nearby-city fallback explanation |
| stay | No | The dates passed to the search, echoed for the widget |
| count | Yes | Number of hotels returned |
| rooms | No | Single-hotel results only: that hotel's room cards, already shown to the user under the hotel |
| hotels | Yes |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, closed-world, and non-destructive behavior. The description adds important behavioral context beyond annotations: it renders as a full map with a multi-hotel list, instructs the agent not to repeat that list in prose, and explains the natural-language query scope.
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 front-loaded with 'DISCOVERY ONLY,' then gives examples, rendering behavior, and the critical exclusion. Every sentence contributes to correct tool selection or invocation.
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 output schema and complete parameter schema coverage, the description supplies the remaining needed context: discovery scope, natural-language capabilities, rendering behavior, and the exact alternative workflow for named hotels.
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 coverage is 100%, so parameter definitions are already well documented. The description adds meaningful semantic guidance for the required query parameter by explaining that it understands hotel types, vibes, traveler types, neighborhoods, and landmarks, though it does not add detail for limit or date 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 uses a specific verb and resource ('search Roomza's hotel database') and clearly scopes it as discovery-only for users who have not named a specific hotel. It explicitly distinguishes this tool from get_hotel, get_hotel_rooms, and show_rooms, so an agent can route correctly without opening sibling schemas.
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 states exactly when to use the tool (city, keyword, natural language discovery) and when never to use it (when the user names one specific hotel). It names the alternative workflow explicitly: get_hotel, then get_hotel_rooms, then show_rooms.
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.
| 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
| 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. When get_hotel_rooms returns no tracked rooms (a roomTypes list instead), call this with hotel_id and no room_ids: it renders the hotel's bookable room types as cards with photos and prices, each linking straight to booking.
| 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. | |
| hotel_id | No | Hotel UUID or slug. Pass INSTEAD of room_ids when get_hotel_rooms found no tracked rooms: shows the hotel's bookable room types as cards. With tracked rooms and no room_ids, shows its top-scored rooms. | |
| room_ids | No | Room UUIDs to display, in ranked order (best first). 1-8 rooms. Omit when passing hotel_id for a hotel with no tracked rooms. | |
| check_out | No | Check-out date YYYY-MM-DD. |
Output Schema
| Name | Required | Description |
|---|---|---|
| stay | No | The dates the card prices are for, echoed for the widget |
| rooms | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds substantial behavior: what each card renders (photo, score, view, bed, price), how prices change based on whether dates are passed, the 1-8 cap, and the fallback rendering mode. This is exactly the context annotations cannot express.
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 mandatory call instruction and the cards-first ordering are front-loaded, which is the right priority. It is long and uses heavy capitalization for emphasis, and a couple of sentences (the 'mandatory even when there is only ONE room' clause) restate the same rule, but every section carries operational 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?
An output schema exists, so return values need no explanation, and the description covers the remaining decisions an agent must make: when to call, source of UUIDs, ordering, date handling, and the no-tracked-rooms fallback. Complete for this tool's complexity.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning: room_ids must be in ranked order best-first and capped at 8, hotel_id is the substitute when no tracked rooms exist, and check_in/check_out materially change displayed prices. Only slight duplication of the schema text keeps it from a 5.
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?
States a specific verb and resource ('show rooms' as rendered cards) and explicitly separates itself from siblings get_hotel_rooms and search results by naming them as the source of UUIDs. An agent can tell immediately that this is the presentation tool, not a retrieval tool.
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?
Gives explicit when-to-use triggers ('whenever you are about to mention, recommend, or describe one or more specific rooms'), explicit exclusions ('NEVER ask the user whether they want to see cards'), the ordering rule (cards first, then prose), and the alternative path (hotel_id fallback when get_hotel_rooms returns no tracked rooms). Nothing is left to inference.
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.
2 tool updates
- Changed
search_hotels9 fields changed- added
Input schema / properties / check_inAdded value: +{ + "description": "Check-in date YYYY-MM-DD, when the user gave dates", + "type": "string" +} - added
Input schema / properties / check_outAdded value: +{ + "description": "Check-out date YYYY-MM-DD", + "type": "string" +} - added
Output schema / properties / hotels / items / properties / guestRatingAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Guest score out of 10 from stays booked through the Nuitee network; not part of the Roomza score" +} - added
Output schema / properties / hotels / items / properties / guestReviewsAdded value: +{ + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Number of guest reviews behind guestRating" +} - added
Output schema / properties / hotels / items / properties / photosAdded value: +{ + "description": "Single-hotel results only: header photos", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / hotels / items / properties / starsAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Supplier-declared star rating" +} - changed
Output schema / properties / hotels / items / requiredPrevious value: -[ - "id", - "name", - "city", - "state", - "country", - "url", - "score", - "reviewCount", - "hotelType", - "vibes", - "neighborhood", - "lat", - "lng", - "photoUrl", - "roomCount", - "roomsWithRecords", - "fromNightly" -]New value: +[ + "id", + "name", + "city", + "state", + "country", + "url", + "score", + "reviewCount", + "hotelType", + "vibes", + "neighborhood", + "lat", + "lng", + "photoUrl", + "roomCount", + "roomsWithRecords", + "fromNightly", + "stars", + "guestRating", + "guestReviews" +] - added
Output schema / properties / roomsAdded value: +{ + "description": "Single-hotel results only: that hotel's room cards, already shown to the user under the hotel", + "items": { + "additionalProperties": false, + "properties": { + "bedType": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "blurb": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "bookUrl": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Type cards only: Roomza stay flow with this room type preselected" + }, + "currency": { + "type": "string" + }, + "floor": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "hotelId": { + "type": "string" + }, + "hotelName": { + "type": "string" + }, + "id": { + "type": "string" + }, + "kind": { + "description": "room = a numbered room with a Roomza record; type = a bookable room type at a hotel with no room records yet", + "enum": [ + "room", + "type" + ], + "type": "string" + }, + "location": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "photoSource": { + "anyOf": [ + { + "enum": [ + "room", + "hotel" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Whether photoUrl shows the actual room or is a hotel-level fallback" + }, + "photoUrl": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "priceNote": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Shown in the price slot when pricePerNight is null, e.g. a prompt to provide dates" + }, + "pricePerNight": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Nightly price for the requested dates; null when no dates were given or no live rate exists" + }, + "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", + "priceNote", + "currency", + "photoUrl", + "photoSource", + "view", + "bedType", + "sqFt", + "blurb", + "url", + "kind", + "bookUrl" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / stayAdded value: +{ + "additionalProperties": false, + "description": "The dates passed to the search, echoed for the widget", + "properties": { + "check_in": { + "type": "string" + }, + "check_out": { + "type": "string" + } + }, + "required": [ + "check_in", + "check_out" + ], + "type": "object" +}
- Changed
show_rooms8 fields changed- added
Input schema / properties / hotel_idAdded value: +{ + "description": "Hotel UUID or slug. Pass INSTEAD of room_ids when get_hotel_rooms found no tracked rooms: shows the hotel's bookable room types as cards. With tracked rooms and no room_ids, shows its top-scored rooms.", + "type": "string" +} - changed
Input schema / properties / room_ids / descriptionPrevious value: -"Room UUIDs to display, in ranked order (best first). 1-8 rooms."New value: +"Room UUIDs to display, in ranked order (best first). 1-8 rooms. Omit when passing hotel_id for a hotel with no tracked rooms." - removed
Input schema / properties / room_ids / minItemsRemoved value: -1 - removed
Input schema / requiredRemoved value: -[ - "room_ids" -] - added
Output schema / properties / rooms / items / properties / bookUrlAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Type cards only: Roomza stay flow with this room type preselected" +} - added
Output schema / properties / rooms / items / properties / kindAdded value: +{ + "description": "room = a numbered room with a Roomza record; type = a bookable room type at a hotel with no room records yet", + "enum": [ + "room", + "type" + ], + "type": "string" +} - changed
Output schema / properties / rooms / items / requiredPrevious value: -[ - "id", - "hotelId", - "hotelName", - "location", - "roomLabel", - "roomNumber", - "floor", - "score", - "reviewCount", - "pricePerNight", - "priceNote", - "currency", - "photoUrl", - "photoSource", - "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", + "kind", + "bookUrl" +] - added
Output schema / properties / stayAdded value: +{ + "additionalProperties": false, + "description": "The dates the card prices are for, echoed for the widget", + "properties": { + "check_in": { + "type": "string" + }, + "check_out": { + "type": "string" + } + }, + "required": [ + "check_in", + "check_out" + ], + "type": "object" +}
1 tool update
- Changed
get_my_trips6 fields changed- added
Output schema / properties / past / items / properties / confirmationNumber / descriptionAdded value: +"Booking reference. For stays booked through Roomza this is the supplier reference until the hotel issues its own number" - added
Output schema / properties / past / items / properties / hotelConfirmationCodeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The hotel's own confirmation number; null until the hotel issues it" +} - changed
Output schema / properties / past / items / requiredPrevious value: -[ - "bookingId", - "hotelId", - "hotelName", - "hotelUrl", - "city", - "state", - "checkIn", - "checkOut", - "nights", - "confirmationNumber", - "bookingPlatform", - "status", - "specialRequests" -]New value: +[ + "bookingId", + "hotelId", + "hotelName", + "hotelUrl", + "city", + "state", + "checkIn", + "checkOut", + "nights", + "confirmationNumber", + "hotelConfirmationCode", + "bookingPlatform", + "status", + "specialRequests" +] - added
Output schema / properties / upcoming / items / properties / confirmationNumber / descriptionAdded value: +"Booking reference. For stays booked through Roomza this is the supplier reference until the hotel issues its own number" - added
Output schema / properties / upcoming / items / properties / hotelConfirmationCodeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The hotel's own confirmation number; null until the hotel issues it" +} - changed
Output schema / properties / upcoming / items / requiredPrevious value: -[ - "bookingId", - "hotelId", - "hotelName", - "hotelUrl", - "city", - "state", - "checkIn", - "checkOut", - "nights", - "confirmationNumber", - "bookingPlatform", - "status", - "specialRequests" -]New value: +[ + "bookingId", + "hotelId", + "hotelName", + "hotelUrl", + "city", + "state", + "checkIn", + "checkOut", + "nights", + "confirmationNumber", + "hotelConfirmationCode", + "bookingPlatform", + "status", + "specialRequests" +]
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
Related MCP Connectors
Live hotel search and booking for AI agents in DACH, the UK and 10 US cities.
Hotels ranked by real comfort, not commission: efficient AC, comfy beds, soundproof rooms and more
Find exact, directly bookable hotel rooms and apartments with live availability and prices.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Related MCP Servers
AirROI Airbnb MCP Serverofficial
AlicenseNot gradedqualityCmaintenanceEnables AI assistants to query short-term rental market data—occupancy, ADR, RevPAR, revenue estimates, comparables, live calendars, search rank, and pricing recommendations—for 20M+ listings across 190+ countries via a remote Streamable HTTP API.MIT- AlicenseNot gradedqualityDmaintenanceAudit any Airbnb, VRBO, or STR listing URL for dollar-denominated revenue gaps. Free tier shows category grades and monthly losses. Pro tier unlocks ranked action plans.19 npmMIT
bookingtruthofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to verify travel bookings against supplier-authoritative evidence, returning honest verdicts like confirmed, held, pending, cancelled, or unknown with citable proof packets.MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.