Skip to main content
Glama

MAQAMI Travel

by co.maqami.mcp
OverviewDiscussionsAdmin

get_data_hotels_room_search

Read-onlyIdempotent

Overview

Beta Feature - Search hotel rooms using visual and text-based queries. Uses image search technology to match your query against room images and find hotels with rooms that match your visual preferences, amenities, or style.

When to Use

  • Visual room search - Find rooms based on visual characteristics like "luxury modernist comfort" or "blue accessible bathroom"

  • Style-based search - Search for rooms by design style like "art deco hotel room" or "brutalist room"

  • Amenity-focused search - Find rooms with specific features like "twin room with a city view" or "room with a skylight"

  • Geographic filtering - Limit results to hotels near a specific location using coordinates or Place ID

  • City and country filtering - Filter results by city and/or country

What You Get

  • Matching hotels - Hotels grouped by hotel ID with rooms that match your query

  • Room details - Room name, image URL, and similarity score (rounded to 3 decimals) for each matching room

  • Hotel metadata - ID, name, address, city, country, and rating for each hotel

  • Geographic filtering - Optionally limit results to a specific area using coordinates or Place ID

  • City and country filters - Filter results by city and/or country code

Example Queries

  • "luxury modernist comfort"

  • "an extremely fun room or art deco hotel room"

  • "luxurious accessible bathroom or blue accessible bathroom with walk in shower"

  • "twin room with a city view"

  • "a room filled with paintings"

  • "a hotel room with a skylight"

Geographic Filtering

You can optionally limit search results to a specific geographic area:

  • Using coordinates: Provide latitude, longitude, and optionally radius (in kilometers, default: 12km)

  • Using Place ID: Provide placeId - the place's location will be automatically fetched and the search will use the place's viewport boundaries (or the provided radius if viewport is unavailable)

  • Using city/country: Provide city and/or country to filter results by location

Quick Start

Provide a query parameter describing the room you're looking for. Optionally add geographic filtering with latitude/longitude or placeId to limit results to a specific area.

Note: This is a beta feature and may be subject to changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoFilter results by city name. Can be used alone or together with country.
limitNoMaximum number of results to return (maps to top_k in the API)
queryYesSearch query describing the room you're looking for. Can be visual (e.g., 'luxury modernist comfort', 'blue accessible bathroom'), amenity-based (e.g., 'twin room with a city view'), or style-based (e.g., 'art deco hotel room', 'brutalist room')
radiusNoSearch radius in kilometers. Only used when latitude/longitude is provided, or when placeId is provided but the place does not have viewport information. When placeId is provided and viewport is available, the viewport boundaries are used instead of this radius. Default is 12km.
countryNoFilter results by country code (ISO 3166-1 alpha-2 format, e.g., 'FR', 'US'). Can be used alone or together with city.
placeIdNoPlace ID. If provided, the search will be limited to hotels within the place's viewport boundaries (or the provided `radius` if viewport is unavailable). The place's latitude and longitude will be automatically fetched.
latitudeNoLatitude coordinate for geographic filtering. Must be provided together with longitude. Ignored if placeId is provided.
longitudeNoLongitude coordinate for geographic filtering. Must be provided together with latitude. Ignored if placeId is provided.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds significant context beyond that: it identifies the feature as beta, describes the image-search technology, details the return structure (hotels grouped by ID with room details and similarity scores), and explains geographic filtering behavior including defaults and viewport precedence. This is valuable behavioral disclosure.

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 markdown headers and bullet lists, making it easy to scan. However, it contains some redundancy—'Geographic filtering' and 'City and country filtering' are listed in both 'What You Get' and separate sections—which slightly detracts from conciseness. Still, it is appropriately sized for a tool with 8 parameters and a beta caveat.

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 absence of an output schema, the description thoroughly explains what the tool returns, including hotel metadata and similarity scores. It also covers all major usage scenarios and geographic filtering modes, and the annotations cover safety. The only minor gap is the lack of sibling differentiation, but the description is otherwise complete for an agent to call this tool correctly.

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 already fully documents all 8 parameters. The description reinforces some parameter usage (query types, geographic filtering) but does not add syntax or constraints beyond what the schema provides. Baseline 3 is appropriate.

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 specific verb (Search) and resource (hotel rooms) with a clear scope (visual and text-based queries). It distinguishes from generic hotel search by focusing on rooms and visual matching, but does not explicitly name any sibling tools to differentiate from them, so it lacks that final level of specificity.

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 'When to Use' section lists five concrete scenarios for using this tool, providing clear context. However, it does not state when not to use it or name alternative tools like get_data_hotels_semantic_search, leaving the agent to infer selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All MAQAMI Travel toolsInspect
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.

Resources