BreckenWander Travel
Server Details
Search flights, hotels & experiences at all-in prices, then build a trip on breckenwander.com.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: searching flights, hotels, experiences, and building a trip. There is no ambiguity or overlap.
All tool names follow a consistent verb_noun pattern (search_flights, search_hotels, search_experiences, build_trip), making it predictable for an agent.
With 4 tools, the server is well-scoped for its domain of travel trip planning, covering all necessary search and combination actions without excess.
The tool set covers the full lifecycle: searching for three core travel components (flights, hotels, experiences) and combining them into a trip. No obvious gaps for its stated purpose.
Available Tools
4 toolsbuild_tripBuild a one-link trip on BreckenWanderARead-onlyInspect
Combine results from previous searches into ONE trip link. Pass the url values of the chosen flight, hotel, and/or experiences (1-8 items, fresh results). Returns trip_url — a single link that opens breckenwander.com with the whole trip pre-loaded in the planner for one checkout (plus trip_page_url, a plain summary fallback). Package-only flight fares become bookable when the trip includes a hotel or experience.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | The `url` values from previous search_flights / search_hotels / search_experiences results (1-8 items). Use fresh results — quotes expire after 30 minutes. | |
| title | No | Optional trip name, e.g. "Rome, Sept 15-20". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: return values (trip_url, trip_page_url) and the bookable fare behavior. Annotations declare readOnlyHint and openWorldHint, which are consistent with generating a link. No contradiction.
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 focused sentences, each adding essential information. No redundancy, front-loaded with main action, and every sentence earns 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?
Given the complexity and lack of output schema, the description covers inputs, outputs, constraints, and a behavioral rule. Minor omission: no explanation of the fallback trip_page_url, but sufficient for most uses.
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% and the description reinforces parameter purposes, adding extra detail about expiry (30 minutes). It adds marginal value beyond the schema 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 explicitly states the tool combines previous search results into a single trip link, uses strong verbs like 'Combine' and 'Returns', and clearly distinguishes from sibling search 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 specifies inputs (url values from searches), constraints (1-8 items, fresh results), and a behavioral note on package fares, but does not explicitly mention when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_experiencesSearch experiences & activities on BreckenWanderARead-onlyInspect
Search tours, activities, and experiences for a destination and get BreckenWander's all-in "from" price (USD). Returns a link that opens that specific experience to book on breckenwander.com. Read-only: does not book or take payment.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adults (context only; final price is set at booking). | |
| date_to | No | Optional end of a date range (YYYY-MM-DD). | |
| children | No | Number of children. | |
| date_from | No | Optional preferred date (YYYY-MM-DD); the exact date is chosen on breckenwander.com. | |
| destination | Yes | City or place name, e.g. "Rome" or "Cancun". | |
| max_results | No | How many experiences to return. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true, openWorldHint=true) and adds context about returning a booking link on breckenwander.com. This goes beyond the annotations' binary hints, offering actionable behavioral details.
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 two sentences, front-loading the core purpose and adding a critical read-only note. Every word serves a purpose, making it highly efficient for an AI agent 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?
For a search tool with 6 parameters (all described in schema) and no output schema, the description sufficiently explains the return value (link, price) and the tool's read-only nature. It complements the schema and annotations well for the given complexity.
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 parameters are well-documented in the schema. The description does not add parameter-specific meaning but provides overall context. This meets the baseline expectation without exceeding it.
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 for tours/activities/experiences by destination, returns an all-in price in USD, and provides a booking link. It distinguishes from siblings like search_flights and search_hotels by focusing on experiences.
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 notes the tool is read-only and does not book or take payment, providing clear usage boundaries. However, it does not explicitly compare with sibling tools or state when not to use it, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_flightsSearch flights on BreckenWanderARead-onlyInspect
Search round-trip flights between two airports for given dates and travelers. Returns BreckenWander's per-traveler round-trip price with taxes and carrier-imposed fees included, plus a link that opens the same search on breckenwander.com to complete the booking. Read-only: does not book or take payment.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result ordering. 'best' (default) balances price, travel time, and stops; 'price' is strictly lowest fare first; 'duration' is shortest outbound travel time first. | best |
| cabin | No | Cabin class. | economy |
| adults | No | Number of adult travelers. | |
| origin | Yes | Origin IATA airport or metro code, e.g. "JFK" or "LON". | |
| infants | No | Number of infant travelers (under 2). | |
| children | No | Number of child travelers (2-11). | |
| max_stops | No | Maximum stops on the outbound leg. 0 returns nonstop flights only. | |
| depart_date | Yes | Departure date in YYYY-MM-DD. | |
| destination | Yes | Destination IATA airport or metro code, e.g. "LAX" or "CUN". | |
| max_results | No | How many flight options to return. | |
| return_date | Yes | Return date in YYYY-MM-DD. Round-trip only for now. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is read-only and does not book or take payment, which aligns with the readOnlyHint annotation. It also explains what is returned (price with taxes and fees, link to complete booking). This adds value beyond the annotations, though there is no mention of other behavioral traits like rate limits or pagination.
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 front-load the core purpose and then provide key return value details. Every sentence adds value without redundancy.
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 (11 parameters, 4 required, no output schema), the description provides a clear high-level understanding. It explains the return value (price and link) but does not detail the structure of each flight option. However, the schema fully documents parameters, making the description adequate for an agent to understand when to use the 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?
The schema has 100% coverage with descriptions for all parameters. The tool description does not add any additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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: searching round-trip flights between airports for given dates and travelers. It uses a specific verb ('Search') and resource ('flights'), and the context of sibling tools (build_trip, search_experiences, search_hotels) makes the distinction unambiguous.
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 specifies that the tool is for round-trip flights only ('Returns BreckenWander's per-traveler round-trip price', and the return_date parameter is described as 'Round-trip only for now'). It does not explicitly state when not to use it or provide alternatives, but 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.
search_hotelsSearch hotels on BreckenWanderARead-onlyInspect
Search hotels for a destination and dates and get BreckenWander's all-in price (every mandatory tax and fee included). Returns a link to complete the booking on breckenwander.com. Read-only: does not book or take payment.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result order. 'price' (default): lowest all-in total first. 'rating': highest guest rating first. 'stars': highest star category first. | price |
| rooms | No | Number of rooms. | |
| adults | No | Number of adults. | |
| check_in | Yes | Check-in date in YYYY-MM-DD. | |
| children | No | Number of children. | |
| check_out | Yes | Check-out date in YYYY-MM-DD. | |
| max_price | No | Only return hotels whose all-in total (whole stay, USD) is at or below this. | |
| min_price | No | Only hotels with an all-in total at or above this. | |
| min_stars | No | Only hotels of at least this star category (e.g. 4). | |
| radius_km | No | Search radius around the destination in km (default ~12). Use a small value like 2 for 'near <landmark>' searches. | |
| destination | Yes | City or place name, e.g. "Rome" or "Cancun". | |
| max_results | No | How many hotels to return. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) are supplemented by description stating 'Read-only: does not book or take payment' and detailing the all-in price and booking link. This adds valuable context beyond the annotations without contradiction.
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 concise sentences, front-loaded with the primary action and context. Every sentence adds value without redundancy.
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, but description hints at output (all-in price, booking link). It covers key aspects but could elaborate on result structure. For a tool with 12 parameters, it is fairly 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%, so baseline is 3. The description does not add meaning beyond the schema; it merely reinforces the all-in price concept already present. No additional parameter semantics are provided.
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 explicitly states 'Search hotels for a destination and dates', clearly identifying the verb (search) and resource (hotels). It distinguishes from sibling tools like search_flights and search_experiences, which are for different travel components.
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 mentions read-only behavior and that it returns a booking link, implying usage for price comparisons without booking. However, it lacks explicit 'when not to use' or direct comparison with siblings, which are implied by context but not stated.
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.
Discussions
No comments yet. Be the first to start the discussion!