Booking gateway for AI agents — discover events, movies & hotels, hand off to partner checkout.
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 4.1/5 across 7 of 7 tools scored. Lowest: 3.4/5.
Each tool has a clear, distinct role: discovery (search, search_all, list_verticals, list_venues), options (find_options), booking (book), and user feedback (request_unsupported_booking). No two tools perform the same function.
Some tools follow verb_noun (list_venues, list_verticals, find_options, request_unsupported_booking), while others are single verbs or verb_adverb (book, search, search_all). The inconsistency in pattern may confuse an agent.
Seven tools is well-scoped for a booking discovery service. Each tool covers a necessary step in the user journey without being overwhelming or sparse.
The set covers the core workflow: discover verticals, search, get options, book, and flag unsupported requests. Minor gaps exist (e.g., no tool to view or cancel bookings), but these are beyond the stated purpose.
bookABook an option (showtime, ticket class, etc.).
If a partner API is connected, completes the booking inline with a confirmation code. Otherwise returns an affiliate deep link the agent should hand to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | For affiliate fallback. | |
| vertical | Yes | The vertical (e.g. "movies", "events"). | |
| option_id | Yes | showtime_id or ticket_id from find_options. | |
| item_title | No | For affiliate fallback / logging. | |
| party_size | No | Number of tickets/seats. Default 2. | |
| venue_name | No | For logging. | |
| agent_client | No | Optional — name of the calling agent (Claude, ChatGPT, etc.). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true. The description adds value by detailing the two outcomes (inline booking vs. affiliate link), clarifying that no actual booking may occur if no partner API is connected. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, conditional behavior, and no wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (2 required) and an output schema, the description covers the main behavioral branches (inline vs. affiliate). It doesn't detail return format (output schema handles that) and assumes domain knowledge (option_id from find_options). Adequate but not exhaustive.
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% (all 7 parameters described). The description adds minimal extra meaning beyond schema; the only addition is explaining affiliate fallback behavior, which is not parameter-specific. Hence baseline 3.
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 starts with 'Book an option (showtime, ticket class, etc.)' clearly stating the verb and resource. It distinguishes from sibling tools like find_options (which finds options) and request_unsupported_booking (handles unsupported cases).
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 explains two scenarios: if partner API connected, completes inline; otherwise returns affiliate deep link. This guides when to expect a confirmation vs. a link, but doesn't explicitly state when not to use or alternatives beyond implicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_optionsAFind concrete bookable options for an item.
For movies: showtimes for the given film. For events: ticket classes.
| Name | Required | Description | Default |
|---|---|---|---|
| when | No | ISO date (YYYY-MM-DD) or "today"/"tomorrow". Default "today". | today |
| item_id | Yes | ID returned by `search` (film_id, event_id), or a title for fuzzy lookup. | |
| location | No | City, postcode, or "lat,lng" — required for movies. | |
| vertical | Yes | The vertical (e.g. "movies", "events"). | |
| agent_client | No | Optional — name of the calling agent (Claude, ChatGPT, etc.). Pass the SAME value across search → find_options → book so the trust stack can link the booking to its prior discovery. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is consistent. It adds value by specifying the output type for different verticals (showtimes vs. ticket classes), which is beyond what annotations provide.
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 extremely concise: two sentences that immediately state the core purpose and provide vertical-specific examples. Every word is necessary, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail return values. It covers the main use cases (movies, events) and mentions key parameters. However, it does not explain the 'when' or 'agent_client' parameters, though the schema covers them.
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%, so the baseline is 3. The description does not add additional meaning beyond the schema; it merely repeats the vertical-specific behavior. No parameter details are elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find concrete bookable options for an item.' It distinguishes itself from siblings by specifying it returns showtimes for movies and ticket classes for events, which differentiates it from search or booking tools.
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 context by mentioning movies and events, but it lacks explicit guidance on when to use this tool versus alternatives like search or list_venues. No exclusions or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_venuesBList venues near a location, marked as bookable or not.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | City, postcode, or "lat,lng". | |
| vertical | Yes | The vertical (e.g. "movies", "events"). | |
| radius_km | No | Search radius. Default 15 km. | |
| agent_client | No | Optional — name of the calling agent (Claude, ChatGPT, etc.). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description aligns by indicating a read operation. However, it adds no extra behavioral details beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that fits the essential purpose without any wasted words.
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 omits important context such as the required 'vertical' parameter or the optional radius. It also does not mention the output schema, though that exists separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully explains parameters. The description does not add new semantic meaning to any parameter.
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 lists venues near a location and indicates their bookable status. This is specific and distinguishes it from siblings like 'book' or 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With six sibling tools, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_verticalsAList all booking verticals Agentorist currently supports.
Returns a dict with each vertical's name and description. Call this first to discover what's bookable before constructing other tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true. The description adds behavioral details about the return structure (dict with name and description) and usage ordering, which adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description has two sentences: the first states purpose, the second adds return format and usage guidance. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers the return value and provides usage context. For a no-parameter tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), and schema description coverage is 100%. Per the guidelines, baseline for 0 params is 4, and the description does not need to add parameter info.
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 resource 'all booking verticals', and specifies the return format as a dict with name and description. It distinguishes from sibling tools by advising to call it first to discover what is bookable.
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 explicitly says 'Call this first to discover what's bookable before constructing other tool calls', giving clear when-to-use context. However, it does not explicitly mention when not to use or list alternatives, though the sibling context fills some gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_unsupported_bookingALog a booking request Agentorist can't yet fulfil.
This is the demand-intelligence engine. Every call here becomes a data point sold to the venue as monthly missed-revenue insight. Optionally captures email so the user is notified when the venue joins.
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | City or area. | |
| vertical | Yes | Which vertical the request belongs to. | |
| when_iso | No | Requested time in ISO 8601 (optional). | |
| item_title | Yes | The film, event, or experience. | |
| party_size | No | Number of tickets. | |
| user_email | No | Optional, for join-notification. | |
| venue_name | Yes | Name of the venue the user wanted. | |
| venue_chain | No | e.g. Vue, Odeon, Cineworld. | |
| agent_client | No | Calling agent (Claude, ChatGPT, etc.). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations by explaining that calls become data points sold to venues and optionally notifies the user via email. Aligns with 'destructiveHint: true' as a record-creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is four sentences, front-loaded with purpose, no wasted words. Efficiently conveys core functionality and business value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing, the description lacks guidance on when to use this tool versus siblings (e.g., 'book', 'search'), prerequisites, or error handling. Adequate for basic understanding but incomplete for optimal selection.
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 has 100% description coverage, so baseline is 3. Description adds minimal parameter-specific meaning, only highlighting 'user_email' for join-notification. Most parameters are explained adequately in 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?
Description uses specific verb 'Log' and resource 'booking request' that aligns with tool name. Differentiates from sibling 'book' by indicating this is for unsupported bookings.
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?
Implicitly suggests use when a booking can't be fulfilled by Agentorist, but does not explicitly state when not to use or mention alternatives like 'search' to check venue support. Lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchASearch for bookable items within a vertical.
| Name | Required | Description | Default |
|---|---|---|---|
| when | No | Optional ISO date filter (YYYY-MM-DD) for events. | |
| query | Yes | Natural-language query — movie title, event keyword, tour name, theme like "beach getaway", etc. | |
| rooms | No | ||
| adults | No | ||
| locale | No | Optional BCP-47 locale ('en-US', 'fr-FR', 'de-DE', 'ja-JP', etc.). Currently consumed by the 'experiences' vertical to localise the Viator response and hand-off URL. Auto-detected from the query when the language is unambiguous. | |
| check_in | No | ||
| children | No | ||
| location | Yes | City, postcode, or "lat,lng". | |
| vertical | Yes | One of the names returned by list_verticals (e.g. "movies", "events", "experiences", "hotels", "cars"). | |
| check_out | No | ||
| territory | No | ISO country code (US, GB, etc.). Default US. | US |
| driver_age | No | ||
| hotel_name | No | ||
| hotel_class | No | ||
| pickup_date | No | ||
| agent_client | No | Optional — name of the calling agent (Claude, ChatGPT, etc.). | |
| budget_range | No | ||
| dropoff_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is read-only. The description adds no further behavioral context beyond the basic search function, which is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words, front-loaded with the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 18 parameters, low schema coverage, and the presence of sibling tools, the description is too minimal. It does not explain how the required 'vertical' relates to list_verticals or how this tool fits into the booking workflow.
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 low (39%) and the tool description adds no parameter meaning beyond what the schema provides. The description does not compensate for the missing parameter details.
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 succinctly states the tool searches for bookable items within a vertical, clearly distinguishing it from sibling 'search_all' which searches across all verticals. It uses a specific verb and resource.
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 ('within a vertical') implying when to use this tool versus search_all, but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_allASearch every Agentorist vertical at once — the answer to "what's on?".
Use this when the user's request spans verticals or doesn't clearly name
one ("what's on tonight", "anything to do in Boston?", "Friday night
plans"). For specific single-vertical queries ("movies tonight",
"Italian restaurants"), search_all auto-narrows to the hinted vertical
so you don't waste calls.
Returns results_by_vertical keyed by movies/events/local, plus
total_count and bookable_total for quick summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| when | No | Optional time hint ("tonight", "weekend", or ISO date). | |
| query | Yes | Natural-language query. Empty string is fine (= browse). | |
| locale | No | Optional BCP-47 locale ('en-US', 'fr-FR', 'de-DE', etc.). Forwarded to verticals that localise their response (experiences). | |
| location | Yes | City, postcode, or "lat,lng". | |
| territory | No | ISO country code (US, GB, etc.). Default US. | US |
| agent_client | No | Optional — name of the calling agent. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true, so description is not contradicted. It adds valuable behavioral context: auto-narrows to hinted vertical, returns structured results (results_by_vertical, total_count, bookable_total). No extra info on auth or rate limits, but adequate for a read-only tool.
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?
Every sentence is purposeful. The core purpose is stated first, then usage guidelines, then return structure. No wasted words. Concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema existence and rich annotations, the description covers all needed context: what it does, when to use, auto-narrowing behavior, and key output fields. For a complex tool with 6 parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds practical meaning: 'empty string is fine (= browse)' for query, 'Optional time hint' for when with examples. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches all Agentorist verticals at once, with a specific verb ('search') and resource ('every vertical'). It distinguishes from siblings like 'search' by explaining auto-narrowing behavior for single-vertical queries.
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?
It explicitly tells when to use (queries spanning verticals or vague) and when not to (specific single-vertical queries it auto-narrows, hinting to use sibling 'search'). Provides concrete examples ('what's on tonight', 'anything to do in Boston?').
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!
