Best-time-to-book verdicts, live last-minute hotel deals, and city price calendars, from data.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.6/5 across 4 of 4 tools scored.
Each tool addresses a distinct aspect: booking advice, calendar events, last-minute deals, and city listing. No functional overlap.
All tool names follow a consistent verb_noun snake_case pattern (get_*, list_*), making them predictable.
With 4 tools, the server is compact yet covers the core functionalities of a hotel booking-timing service.
The tool set provides all necessary operations for the declared domain: advice, calendar, deals, and city discovery. No obvious gaps.
get_booking_adviceBest time to book adviceBInspectGet a data-backed verdict on whether to book a hotel now or wait, for a city and stay dates. Based on tracked daily median prices.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name, e.g. 'Lisbon' | |
| checkIn | Yes | Check-in date, YYYY-MM-DD | |
| checkOut | Yes | Check-out date, YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions data source ('tracked daily median prices') but fails to disclose return format, caching, limitations (e.g., city coverage), or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no waste, front-loaded with the core action. Could include more detail without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; the tool returns a verdict but the description does not describe the response format or what constitutes a 'verdict'. Incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no further meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get a data-backed verdict' with resource 'whether to book now or wait', which is distinct from siblings like get_city_calendar (calendar view) and get_last_minute_deals (deals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for booking timing advice but lacks explicit guidance on when to use this tool versus alternatives like get_city_calendar or get_last_minute_deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_city_calendarCity price calendarAInspectHot dates (events and holidays that push hotel prices up) and value windows (historically cheaper stretches) for a city in a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Range end, YYYY-MM-DD (default: one year from today) | |
| city | Yes | City name, e.g. 'Lisbon' | |
| from | No | Range start, YYYY-MM-DD (default: today) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral context. It only describes what the tool returns (hot dates and value windows) but omits details like data source, update frequency, or if it is read-only, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads key terms ('Hot dates' and 'value windows') with zero waste, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not detail the return format or structure of hot dates and value windows, which is a gap for a moderately complex tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions (city, from, to). The description adds minimal extra meaning beyond stating the tool's purpose, so it meets but does not exceed the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'hot dates' and 'value windows' for a city in a date range, effectively distinguishing it from sibling tools like get_booking_advice or get_last_minute_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving price calendar data but does not explicitly state when to use this tool over alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_last_minute_dealsLast-minute hotel dealsAInspectCurrent last-minute hotel deals in a city: live rates below each hotel's tracked typical price, plus hotels that historically drop prices close to check-in.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name, e.g. 'Lisbon' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It reveals that deals include 'live rates below each hotel's tracked typical price' and hotels that 'historically drop prices', which is useful behavioral context. However, it does not mention data freshness, caching, or any side effects, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the main purpose. Each sentence adds value: the first defines the output, the second clarifies the deal comparison. Minor structural improvement could include bullet points for clarity, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter with full schema coverage and no output schema, the description should elaborate on the response format. It mentions 'live rates' and 'typical price' but not whether the output is a list of hotels, price reductions, or percentages. This gap reduces completeness for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'city' parameter described as 'City name, e.g. 'Lisbon''. The description only restates that deals are 'in a city', adding no new meaning beyond the schema. Baseline 3 is appropriate as the parameter is simple and well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'current last-minute hotel deals in a city' and specifies the comparison to 'tracked typical price' and historical patterns. This uniquely identifies the tool's purpose and distinguishes it from siblings like 'get_booking_advice' which offers booking recommendations, and 'get_city_calendar' which shows events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to find last-minute deals) but does not explicitly state when not to use it or mention alternatives. It lacks guidance on prerequisites or comparison with siblings, relying on the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_citiesList covered citiesAInspectList the cities with hotel booking-timing data on Best Time to Book Hotels. Optionally filter by a search string. Call this first to learn coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional filter matched against city and country names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the tool is read-only and non-destructive ('List'), but does not disclose output structure or potential limitations. For a simple list tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded in the first sentence, and usage guidance appears immediately after, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's role and primary use case. However, it lacks detail about the output format (e.g., whether it returns city names, objects, or markers), which would be useful for agents. Minor gap, but overall complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description restates the parameter's purpose ('Optionally filter by a search string'). This matches the baseline for high coverage, adding no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'cities with hotel booking-timing data'. It explicitly distinguishes from sibling tools by explaining the tool's role as an initial discovery step ('Call this first to learn coverage').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Call this first to learn coverage'), implying it should be used before other tools. However, it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!