F
licenseNot graded
qualityC
maintenanceEnables AI assistants to search local businesses, check real-time availability, and create instantly confirmed bookings for tables, appointments, or classes without an API key.
agentorist
Server Details
Booking gateway for AI agents — discover events, movies & hotels, hand off to partner checkout.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
7 toolsbookADestructiveInspect
Book 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.
ParametersJSON Schema
| 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.). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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_optionsARead-onlyInspect
Find concrete bookable options for an item.
For movies: showtimes for the given film. For events: ticket classes.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/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. 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.
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: '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.
Usage Guidelines3/5
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_venuesBRead-onlyInspect
List venues near a location, marked as bookable or not.
ParametersJSON Schema
| 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.). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.4/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines2/5
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_verticalsARead-onlyInspect
List 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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_bookingADestructiveInspect
Log 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.
ParametersJSON Schema
| 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.). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
searchARead-onlyInspect
Search for bookable items within a vertical.
ParametersJSON Schema
| 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 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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_allARead-onlyInspect
Search 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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.7/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Discover and book businesses via AI agents.
AI ticket commerce for theme parks, zoos, museums, and aquariums via any AI agent
Flight search & booking for AI agents. 400+ airlines, $20-50 cheaper than OTAs.
Related MCP Servers
- AlicenseAqualityCmaintenanceHotel booking MCP server — the first transaction-complete hotel booking integration for AI agents. Search 300K+ properties in 140+ countries, get live rates and room details, and generate secure checkout URLs. No payment in the AI conversation — guests complete booking at a hosted checkout page and receive a real hotel confirmation number. Set your own booking fee via Stripe Connect.8172Unlicense - libtelnet variant
Dida Hotel MCPofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.81MIT- AlicenseNot gradedqualityCmaintenanceLuxury hotel intelligence and secure checkout handoff for AI travel agents.1Apache 2.0
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.9/5.0
Disambiguation5/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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.