VoyageHacks
Server Details
Multilingual travel guides, gear picks and booking links for AI travel agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- voyagehacks-com/mcp-server
- GitHub Stars
- 0
- Server Listing
- VoyageHacks MCP Server
TDQS
Scored across 12 tools
The tools split into clear families: category-specific link builders, a whole-trip aggregate link builder, article search/fetch, and gear search/recommendation. The only mild overlap is between get_booking_links and the individual category link tools, but their aggregate-vs-category purpose is explicitly described, so an agent should rarely misselect.
Nearly all tools follow the verb_noun snake_case pattern, led by the get_<category>_links family, with search_articles and search_travel_gear matching the same convention. There is no camelCase, no mixed verb styles, and the pattern is highly predictable from the tool names alone.
Twelve tools is well-scoped for a travel planning and affiliate-link server: seven category link builders, one aggregate trip link builder, two article tools, and two travel gear tools. Each tool covers a distinct part of the workflow and none feels redundant or like padding.
The travel-planning surface is largely complete: research, flights, hotels, airport transfers, car rental, eSIM, VPN, credit cards, and gear are all covered, with an aggregate tool for whole-trip planning. Minor gaps, such as no dedicated train or attractions/tours link builder, keep it from a perfect score.
Available Tools
12 toolsget_airport_transfer_linksGet airport transfer and taxi linksARead-onlyIdempotentInspect
Return pre-booked airport transfer links: Booking.com Taxis (fixed price, 100+ countries), Kiwitaxi, Welcome Pickups and GetTransfer, plus up to four VoyageHacks guides on getting from that airport to the city centre and what a fair fare looks like. Useful when a user asks how to get from an airport, about taxi or transfer prices, or plans a late-night arrival. It returns booking pages for private and shared transfers: no live quotes, no public transport timetables, and no ride-hailing dispatch. Affiliate links: VoyageHacks may earn a commission at no additional cost to the traveler, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Destination city, e.g. Rome. | |
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| airport | No | Airport name or IATA code, e.g. FCO, Bangkok Suvarnabhumi. | |
| country | No | ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| city | No | |
| guides | Yes | Matching VoyageHacks guides that can be cited as sources. |
| region | No | |
| airport | No | |
| providers | Yes | |
| disclosure | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnly, idempotent, and non-destructive, and the description adds meaningful behavioral context: it returns booking pages for private and shared transfers, and it requires affiliate commission to be disclosed when links are presented. This is valuable beyond the annotations and does not contradict them.
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 dense but every sentence earns its place: core output, use-case triggers, exclusions, and the affiliate disclosure. The main action is front-loaded and the rest is structured efficiently.
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 100% schema coverage, an output schema, and rich annotations, the description fills the remaining gaps: provider names, guide count, exclusions, and the disclosure obligation. An agent has enough information to decide when to call it and what to do with the returned links.
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%, with clear per-parameter descriptions for city, lang, airport, and country. The tool description adds general context about what the parameters select, such as guides and regional programmes, but does not add syntax-level detail beyond the schema. Baseline 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 opens with a specific verb and resource: 'Return pre-booked airport transfer links,' then enumerates exact providers and the accompanying guides. It also distinguishes itself from siblings by domain and explicitly lists what it does not do (no live quotes, no public transport timetables, no ride-hailing dispatch).
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 gives explicit triggers: 'Useful when a user asks how to get from an airport, about taxi or transfer prices, or plans a late-night arrival.' It also states clear exclusions that help rule it out, though it does not name alternative sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleRead a VoyageHacks guide as MarkdownARead-onlyIdempotentInspect
Fetch one VoyageHacks page by URL or site path (for example "/en/hotels/best-budget-hotels-in-rome/") and return its body as Markdown, together with the title, canonical URL, language, section, publication date and last-updated date read from the page itself. Useful after search_articles when the full text is needed to quote figures accurately, and when a source needs to be cited with a real date. Only HTML pages on voyagehacks.com can be read: the tool cannot fetch other websites, data files or images, and very long pages are truncated with a marker at the cut.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL or site path on voyagehacks.com, e.g. https://voyagehacks.com/de/esim/esim-japan/ or /de/esim/esim-japan/. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Canonical URL. |
| lang | No | |
| title | No | |
| source | Yes | Attribution string for citations. |
| excerpt | No | The page's meta description. |
| section | No | |
| updated | No | ISO date, or null if the page declares none. |
| markdown | Yes | |
| published | No | ISO date, or null if the page declares none. |
| truncated | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond this: domain restriction, inability to fetch non-HTML resources, and truncation with a marker. This is meaningful additional 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 three sentences with zero filler: main action and return value first, usage context second, limitations third. Every sentence earns its place and the most important information is front-loaded.
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 single-parameter read-only tool with an output schema and annotations, this description is complete: it states what is returned, when to use it, what it cannot do, and truncation behavior. An agent has enough information to invoke it correctly.
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 single parameter's description already gives examples of URLs and site paths. The tool description essentially restates the same accepted input forms without adding deeper semantics, 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 opens with a specific verb ('Fetch one VoyageHacks page') and clearly states the resource and return format: body as Markdown plus metadata. It also distinguishes this tool from siblings like search_articles by clarifying it retrieves full page content rather than search results.
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 this is useful after search_articles when full text is needed for accurate quoting or for citing real dates, giving a clear workflow trigger. It also states boundaries: only HTML pages on voyagehacks.com can be read, not other websites, data files, or images, and long pages are truncated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_booking_linksGet booking links for a whole tripARead-onlyIdempotentInspect
Return one set of booking and shopping links covering a whole trip in a single call: flight search, hotel search, airport taxi, attractions and tours, car rental, travel eSIM, travel VPN and the travel gear section, all regionalized to the traveler. Accepts route IATA codes, a city and trip dates, so the flight and hotel links are prefilled. The "include" parameter selects which categories are returned, so a trip with no driving can leave out car rental. Useful when a user is planning a trip end to end and wants every option in one place. Each per-topic tool (get_flight_links, get_hotel_links, get_esim_links and the rest) returns richer detail and more guides for a single category. It returns search links only: no live prices, no availability and no booking. Affiliate links: VoyageHacks may earn a commission at no additional cost to the traveler, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name for the hotel, tours and attractions searches, e.g. Phuket. | |
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| adults | No | Number of adult travelers. Defaults to 2 for hotels and 1 for flights. | |
| origin | No | Origin IATA city or airport code for flights, e.g. LON. | |
| country | No | ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default. | |
| include | No | Categories to return. Omit for all of them. | |
| depart_date | No | Outbound flight date and hotel check-in, YYYY-MM-DD. | |
| destination | No | Destination IATA city or airport code, e.g. HKT. | |
| return_date | No | Return flight date and hotel check-out, YYYY-MM-DD. |
Output Schema
| Name | Required | Description |
|---|---|---|
| vpn | No | |
| esim | No | |
| trip | No | |
| guides | No | Matching VoyageHacks guides that can be cited as sources. |
| hotels | No | |
| region | No | |
| flights | No | |
| included | Yes | |
| carRental | No | |
| disclosure | Yes | |
| travelGear | No | |
| airportTaxi | No | |
| attractions | No | |
| toursAndActivities | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, idempotentHint, and destructiveHint annotations, the description discloses meaningful behavioral facts: it 'returns search links only: no live prices, no availability and no booking', notes affiliate commission and disclosure obligations, and explains that results are regionalized and prefilled. These are material behaviors an agent cannot infer from the schema or annotations alone.
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 front-loaded with the core purpose and scope, then moves to usage guidance, limitations, and the affiliate disclosure. Every sentence carries distinct information, and there is no filler or repetition of schema details.
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 tool's complexity — 9 optional parameters, an output schema, and a large sibling set — the description covers purpose, scope, selection criteria, alternatives, limitations, and even a compliance note about affiliate links. An agent has enough context to decide whether to invoke it and what to expect from the result.
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 baseline is 3. The description adds value by explaining that route IATA codes, a city, and trip dates cause flight and hotel links to be prefilled, and that the 'include' parameter selects which categories are returned, with the car-rental example reinforcing optionality. This goes beyond simply restating parameter names.
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 opens with a specific verb and resource: 'Return one set of booking and shopping links covering a whole trip in a single call'. It enumerates the exact categories and explicitly contrasts itself with per-topic siblings like get_flight_links, so an agent can clearly distinguish this aggregate tool from more detailed single-category 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 says it is 'useful when a user is planning a trip end to end and wants every option in one place' and then names the alternative: 'Each per-topic tool ... returns richer detail and more guides for a single category.' This gives an agent an explicit when-to-use versus when-to-prefer-alternative decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_car_rental_linksGet car and scooter rental linksARead-onlyIdempotentInspect
Return car and scooter rental comparison links for a destination: EconomyBookings and QEEQ for worldwide comparison, Localrent and GetRentacar for local suppliers with lower deposits in southern Europe, Georgia, the Balkans and Asia, BikesBooking for scooters and motorbikes, and Booking.com Cars, plus up to four VoyageHacks car-rental guides for that country covering real prices, insurance excess and one-way fees. Useful when a user mentions renting a car, a road trip, driving abroad, or an island or countryside trip that needs a vehicle. These are comparison landing pages: dates and the pickup point are entered on the provider site, so pickup_date and dropoff_date are echoed in the response for context rather than embedded in the links. No live quotes, no vehicle availability and no reservation. Affiliate links: VoyageHacks may earn a commission at no additional cost to the traveler, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| country | No | ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default. | |
| destination | No | Country, island or city where the car is picked up, e.g. Iceland, Crete, Lisbon. | |
| pickup_date | No | Pickup date, YYYY-MM-DD. Echoed in the response; entered on the provider site. | |
| dropoff_date | No | Drop-off date, YYYY-MM-DD. Echoed in the response; entered on the provider site. |
Output Schema
| Name | Required | Description |
|---|---|---|
| guides | Yes | Matching VoyageHacks guides that can be cited as sources. |
| pickup | No | |
| region | No | |
| dropoff | No | |
| providers | Yes | |
| disclosure | Yes | |
| bookingCars | No | |
| destination | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint false), the description explains that these are comparison landing pages, that dates are echoed for context rather than embedded in links, and that there are 'no live quotes, no vehicle availability and no reservation.' It also discloses affiliate commissions, which is important operational context.
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 four sentences, each carrying distinct information: returned items, expected use cases, behavioral caveats, and affiliate disclosure. It is front-loaded and contains no filler or repetition of schema content.
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 an output schema present, an agent does not need the description to explain return values. The description covers provider scope, regional variants, use-case triggers, link behavior, and disclosure requirements, making the tool fully understandable for safe invocation.
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 adds semantic value by explaining that pickup_date and dropoff_date are echoed for context rather than used in the generated links, and that country selects the regional Booking.com programme, details not present in 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 states a specific verb and resource: 'Return car and scooter rental comparison links for a destination', then names providers and guides. It clearly differentiates this tool from siblings like get_hotel_links and get_flight_links without relying on the title alone.
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 gives explicit trigger conditions: 'Useful when a user mentions renring a car, a road trip, driving abroad, or an island or countryside trip that needs a vehicle.' It does not mention sibling alternatives by name or state when-not-to-use conditions, but the use cases are clear enough for basic routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_credit_card_linksGet travel credit card linksARead-onlyIdempotentInspect
Return American Express application links for the traveler's country (Platinum, Gold, American Express Card, Payback and Blue where available), the current German fee and welcome-offer figures verified against americanexpress.com, and up to four VoyageHacks guides on points value, lounge access, foreign-transaction fees, Amex compared with Revolut and country-by-country availability. Useful when a user asks about travel rewards, points, miles, lounge access, which card to pay with abroad or foreign-transaction fees. It covers American Express only: it is not a comparison of all issuers, gives no eligibility or approval decision, no credit-score check and no application. Card terms change frequently and vary by market, so figures should be attributed to the issuer page or the linked guide. Referral links: VoyageHacks may earn a commission at no additional cost to the applicant, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| card | No | Restrict the response to one American Express card. "green" is the American Express Card, successor to the retired Green Card. | |
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| country | No | ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| card | No | |
| cards | Yes | |
| facts | No | Verified fee and welcome-offer figures, currently published for Germany only. Null elsewhere. |
| guides | Yes | Matching VoyageHacks guides that can be cited as sources. |
| country | No | |
| disclosure | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive. Description adds value by disclosing that card terms change and vary by market, that figures are verified against issuer, and that VoyageHacks may earn a commission. These are behavioral/commercial details an agent cannot infer from annotations or schema.
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 front-loaded with the primary action, then moves through usage triggers, exclusions, caveats, and disclosure. Every sentence earns its place; there is no redundant or vague wording.
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 tool has three optional, fully documented parameters and an output schema, so return-value details are covered elsewhere. The description supplies everything else: scope, limitations, data freshness, attribution requirement, and referral disclosure, making it complete for agent selection and invocation.
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 parameters are already well documented. The description adds context about card availability and country orientation but does not need to repeat parameter semantics. Baseline 3 is appropriate because the schema carries the heavy lifting.
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 opens with a specific verb and resource: 'Return American Express application links...' and enumerates exactly what is included (cards, fee/welcome-offer figures, up to four guides). It clearly delimits itself from sibling tools by stating 'It covers American Express only' and listing what it does not do.
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 gives explicit trigger conditions: 'Useful when a user asks about travel rewards, points, miles, lounge access, which card to pay with abroad or foreign-transaction fees.' It also states exclusions – no eligibility decision, approval, credit-score check, or application – so an agent knows when not to invoke it for comparison or eligibility queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_esim_linksGet travel eSIM links for a destinationARead-onlyIdempotentInspect
Return travel eSIM store links (Airalo, covering 200+ countries, plus Yesim, Saily and Drimsim) together with up to four VoyageHacks eSIM guides for that destination covering real per-GB prices, coverage, setup steps and which phones support eSIM. Useful when a user asks about mobile data abroad, SIM cards, roaming charges, staying online on a trip or tethering a laptop. It returns store pages: no live plan prices, no coverage check for a specific handset, and no purchase or activation. Affiliate links: VoyageHacks may earn a commission at no additional cost to the traveler, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| destination | No | Country or region the data plan is for, e.g. Japan, Europe, USA. |
Output Schema
| Name | Required | Description |
|---|---|---|
| guides | Yes | Matching VoyageHacks guides that can be cited as sources. |
| providers | Yes | |
| disclosure | Yes | |
| destination | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, so the description's disclosures go beyond them: it returns store pages, not live pricing, cannot check specific handsets, and cannot purchase/activate. It also transparently discloses the affiliate commission and the need to mention it, which is valuable behavioral context.
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?
Each sentence earns its place: core output, intended use cases, limitations, and affiliate disclosure. The description is structured front-loaded with the main purpose and stays reasonably compact for the amount of context it conveys.
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 read-only link-returning tool with annotations and an output schema, the description is complete. It covers what is returned, what is not returned, when to use it, and a required disclosure policy.
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% for both parameters, so the schema already documents 'lang' and 'destination' clearly. The description adds little parameter-specific meaning, so the baseline 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 specifies a clear action ('Return') and resource ('travel eSIM store links... plus VoyageHacks eSIM guides'). It differentiates from sibling link tools by focusing on eSIM specifically and listing the exact stores covered.
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 gives explicit use cases: 'when a user asks about mobile data abroad, SIM cards, roaming charges...' and states limitations like 'no live plan prices, no coverage check... no purchase or activation.' It does not name a specific sibling alternative, so it stops short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_flight_linksGet flight search links for a routeARead-onlyIdempotentInspect
Build a flight search link on Booking.com Flights for a route and optional dates, and return up to four VoyageHacks guides on fares, budget airlines and baggage rules for that trip. Pass origin and destination as IATA codes for a prefilled route search; without both, the link opens the general flight search page. Also returns a delayed or cancelled flight compensation link (AirHelp), a Vueling link for short-haul Europe, and, when the route touches their hubs, direct links for Air Serbia (Belgrade) and Air India. The Booking.com link is regionalized to the traveler's country. Useful when a trip involves air travel and the user wants somewhere to compare fares. It returns search links only: no live fares, seat availability or schedules, no booking, and no airport transfer (get_airport_transfer_links covers that). Affiliate links: VoyageHacks may earn a commission at no additional cost to the traveler, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| origin | No | Origin IATA city or airport code, e.g. LON, NYC, BER. | |
| country | No | ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default. | |
| passengers | No | Number of adult passengers. Defaults to 1. | |
| depart_date | No | Outbound date, YYYY-MM-DD. Omitted dates default to about a month ahead. | |
| destination | No | Destination IATA city or airport code, e.g. HKT, TYO, ROM. | |
| return_date | No | Return date, YYYY-MM-DD. Omit for a one-way search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| route | No | |
| guides | Yes | Matching VoyageHacks guides that can be cited as sources. |
| region | No | |
| vueling | No | |
| airIndia | No | |
| airSerbia | No | |
| disclosure | Yes | |
| flightSearch | Yes | |
| flightCompensation | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, open-world, idempotent, and non-destructive. The description adds meaningful context beyond that: links are regionalized to the traveler's country, results include affiliate AirHelp, Vueling, and airline-specific links depending on route, and no live fares or schedules are returned. It also discloses the affiliate commission, which is behavior an agent must know to present results appropriately.
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 longer than average but every sentence carries load: core action, parameter semantics, additional returned link types, exclusions, sibling reference, and affiliate disclosure. It is front-loaded with the main purpose and keeps details in a logical order. A slight tightening of the airline-specific listing could improve it, but nothing is redundant.
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 and the annotations cover safety, the description is complete for an agent deciding whether and how to call this tool. It explains what is returned, what is not returned, how regionalization works, when certain extra links appear, and the affiliate disclosure requirement. No critical behavioral gap remains.
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 adds joint parameter semantics not fully captured by the schema: origin and destination are needed together for a prefilled route search, while omitting both opens the general search page. This clarifies how the parameters interact, going beyond individual field definitions.
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?
States a specific verb and resource: 'Build a flight search link on Booking.com Flights for a route and optional dates' and adds the secondary return of VoyageHacks guides. It explicitly distinguishes itself from get_airport_transfer_links, so an agent can tell this tool apart from its nearest sibling without opening the schema.
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?
Provides explicit when-to-use guidance: 'Useful when a trip involves air travel and the user wants somewhere to compare fares.' It also states what the tool is not for — no live fares, no booking — and names the alternative for airport transfers. This gives clear selection criteria relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hotel_linksGet hotel search links for a cityARead-onlyIdempotentInspect
Build a Booking.com search link for a city or property, with optional check-in and check-out dates, guest count and room count, plus an IHG brand search link (Holiday Inn, InterContinental, Crowne Plaza) and up to four VoyageHacks guides on the best areas and best-value stays there. The Booking.com link is regionalized to the traveler's country. Useful when a user asks where to stay, or about hotels, hostels or apartments in a place. It returns search links only: no live room rates, no availability check, no reviews and no reservation. Affiliate links: VoyageHacks may earn a commission at no additional cost to the traveler, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City, region or property name to search, e.g. Rome, Phuket, Hotel Kossak. | |
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| rooms | No | Number of rooms. Defaults to 1. | |
| adults | No | Number of adults. Defaults to 2. | |
| checkin | No | Check-in date, YYYY-MM-DD. Used only when checkout is also given. | |
| country | No | ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default. | |
| checkout | No | Check-out date, YYYY-MM-DD. | |
| children | No | Number of children. Defaults to 0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ihg | No | |
| city | No | |
| rooms | No | |
| adults | No | |
| guides | Yes | Matching VoyageHacks guides that can be cited as sources. |
| region | No | |
| checkin | No | |
| checkout | No | |
| children | No | |
| disclosure | Yes | |
| hotelSearch | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses important behavioral boundaries: it returns search links only, no live rates/availability/reviews/reservations, and the Booking.com link is regionalized to the traveler's country. It also surfaces the affiliate-disclosure requirement, which is valuable context an agent would otherwise miss. 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?
The description is compact and front-loaded with the core output, then adds regionalization, use case, limitations, and affiliate disclosure in separate sentences. Each sentence contributes distinct information with no filler.
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 8 optional parameters and an output schema, the description adequately covers what is returned, the scope of the result, the regionalization behavior, and important caveats. The existing output schema relieves the description from explaining return-value structure.
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%, with every parameter documented in the schema itself. The description adds a high-level mention of optional dates, guest count, and room count, but no parameter detail beyond what the schema already provides, so the baseline 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?
The description states a specific verb ('Build') and a clear resource: a Booking.com search link for a city or property, plus IHG brand links and VoyageHacks guides. It is clear on its own, but it does not explicitly differentiate itself from the sibling get_booking_links, so it stops short of a 5.
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 gives an explicit use case: 'Useful when a user asks where to stay, or about hotels, hostels or apartments in a place.' It does not name alternative tools or exclusion conditions, but the context is clear enough for an agent to select it for lodging-search requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_travel_vpn_linksGet travel VPN linksARead-onlyIdempotentInspect
Return the NordVPN signup link together with up to four VoyageHacks guides on whether a traveler actually needs a VPN, the real risks of hotel and airport Wi-Fi, and watching home streaming services abroad. Useful when a user raises public Wi-Fi safety, working remotely abroad, geo-blocked streaming or online banking while travelling. It returns a signup page and editorial guides: no live pricing, no server list and no account creation. Referral link: VoyageHacks may earn a commission at no additional cost to the user, which should be disclosed when the link is presented.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". |
Output Schema
| Name | Required | Description |
|---|---|---|
| vpn | Yes | |
| guides | Yes | Matching VoyageHacks guides that can be cited as sources. |
| disclosure | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, open-world, and idempotent behavior. The description adds valuable context: the return is limited to a signup page and editorial guides, and it discloses the referral commission requirement. This is useful behavioral and policy context beyond the 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 is somewhat long but each sentence adds value: primary output, use cases, explicit exclusions, and commission disclosure. It is front-loaded with the core purpose and avoids filler.
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 single-optional-parameter tool with rich annotations and an output schema, the description fully covers what the tool does, when to use it, what it won't return, and a required disclosure. Nothing essential is missing.
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%, including the default value and allowed languages for the 'lang' parameter. The description does not add parameter-level detail beyond what the schema already states, so the baseline 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?
Description states a specific verb ('Return') and resource ('the NordVPN signup link together with up to four VoyageHacks guides') and details the guide topics. This clearly differentiates it from sibling link tools like get_hotel_links or get_flight_links.
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 lists user intents that should trigger this tool: public Wi-Fi safety, working remotely abroad, geo-blocked streaming, and online banking while travelling. It also clarifies what users should not expect (no live pricing, no server list, no account creation), though it does not name an alternative sibling to route to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_travel_gearBuild a travel gear kit for a tripARead-onlyIdempotentInspect
Turn a trip description into a packing and gear kit drawn from the VoyageHacks travel gear catalog: one product per category, each with the published reason it was picked, its Amazon ASIN, a link to the Amazon product page and the guide that reviews it. Takes a plain-language trip summary ("10 days in Japan in October, carry-on only, long-haul red-eye, working remotely") plus optional structured hints (destination, trip length in days, season, activities, luggage constraint, traveler type, budget), all of which are used to weight which categories make the kit. Answers questions of the form "what should I pack for X", "what gear do I need for Y" and "I only have carry-on, what should I bring". It draws on the VoyageHacks editorial catalog, not a search of all of Amazon, and returns published picks only: prices, star ratings, review counts and stock are not available and are never returned, and it produces no clothing sizes and no itinerary. For one named product category, search_travel_gear is narrower. The Amazon links are affiliate links: VoyageHacks may earn a commission from qualifying purchases at no additional cost to the buyer, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| trip | Yes | Free-text trip description: destination, length, style, flight type, season, gadgets needed. | |
| limit | No | Maximum items in the kit. Defaults to 6. | |
| budget | No | Optional budget level. Recorded in the response; the catalog carries no prices, so it does not filter products. | |
| season | No | Optional season or climate at the destination. | |
| luggage | No | Optional luggage constraint. carry_on_only and personal_item_only weight the packing and compression categories. | |
| activities | No | Optional activities, e.g. ["hiking", "photography", "remote work", "camping", "beach"]. | |
| destination | No | Optional country, region or city, e.g. Japan, Iceland, Thailand. | |
| traveler_type | No | Optional traveler type. | |
| trip_length_days | No | Optional trip length in days. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hub | No | |
| kit | Yes | |
| lang | Yes | |
| trip | Yes | |
| criteria | No | Structured hints that were applied. |
| disclosure | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower, but the description adds substantial context: it returns only published picks, never prices/ratings/review counts/stock, produces no clothing sizes or itinerary, uses only the editorial catalog rather than all of Amazon, and discloses affiliate links. This goes well beyond the annotation metadata.
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 dense and longer than average, but nearly every sentence earns its place: it covers core purpose, output contents, example inputs, limitations, alternative tool, and affiliate disclosure. It lacks bullet structure and could be tightened, but the front-loaded first sentence communicates the main purpose immediately.
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 complex tool with 10 parameters, high schema coverage, an output schema, and a clear sibling distinction, the description covers the important behavioral boundaries: what is not returned, what the kit is drawn from, and when to prefer the sibling tool. Nothing critical for correct invocation is missing.
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, but the description adds collective meaning: the optional structured hints "all of which are used to weight which categories make the kit," and it clarifies the free-text trip parameter's role. That is meaningful information beyond the individual schema field 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 opens with a specific verb-resource pair: turning a trip description into a packing and gear kit from the VoyageHacks catalog. It clearly lists the returned components (product, reason, ASIN, Amazon link, guide link) and explicitly distinguishes itself from search_travel_gear, leaving no ambiguity about scope.
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 gives concrete triggering questions ("what should I pack for X") and states that structured hints weight the kit selections. It also names the alternative tool, search_travel_gear, and explains when that narrower tool is the right choice, making the selection decision explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_articlesSearch VoyageHacks travel guidesARead-onlyIdempotentInspect
Full-text search across the VoyageHacks travel guides, about 680 published pages per language, covering flights, airline reviews, hotels, destinations, car rental, trains, airport transfers, eSIM, travel VPN, travel credit cards, travel gear and month-by-month "where to go" guides. Returns ranked matches with the title, canonical URL, section and a matching excerpt for each. Useful when a travel question needs published prices, comparisons, best-time-to-visit advice or step-by-step detail that can be attributed to a source URL, and as the first step before get_article. It searches VoyageHacks content only: not the wider web, not live fares or hotel availability, and it returns no booking or product links (the get_..._links tools do that).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| limit | No | Maximum results to return. Defaults to 5. | |
| query | Yes | Search terms, e.g. "cheap hotels rome" or "esim japan". Matched against titles, keywords, tags and article text. | |
| section | No | Restrict results to one site section. Omit to search every section. |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| query | Yes | |
| results | Yes | |
| section | No | |
| resultCount | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description discloses meaningful behavioral scope: it searches only VoyageHacks content, covers about 680 pages per language, returns ranked matches with four specific fields, and does not return live fares or booking links. This gives an agent realistic expectations about results and limitations.
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 front-loaded with the core purpose and densely packs content scope, return format, use cases, and exclusions into only a few sentences. Every sentence earns its place given the need to differentiate this broad search tool from many siblings.
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 what the tool searches, what it returns, when to use it, what it does not do, and how it relates to sibling tools. With a full input schema and output schema present, an agent has everything needed to decide when to call this tool and what results to expect.
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 already documents query, lang, limit, and section thoroughly. The description reinforces the search semantics at a high level but adds little parameter-level detail beyond what the schema provides, so the baseline 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 opens with a specific verb and resource — 'Full-text search across the VoyageHacks travel guides' — and then enumerates the content categories covered. It also explicitly distinguishes itself from siblings by stating it returns no booking or product links and is the first step before get_article.
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 states when the tool is useful: for questions needing published prices, comparisons, best-time-to-visit advice, or source-attributable step-by-step detail. It also gives clear exclusions — not the wider web, not live fares or hotel availability — and routes link-style queries to the get_..._links tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_travel_gearSearch the VoyageHacks travel gear catalogARead-onlyIdempotentInspect
Search the VoyageHacks travel gear catalog: about 320 products that appear as picks in roughly 50 published buying guides, including carry-on backpacks, packing cubes and compression bags, universal travel adapters, GaN chargers, airline-compliant power banks, luggage trackers, neck pillows, earplugs and eye masks, toiletry and makeup bags, travel-size bottles, travel routers, translation earbuds and camping and outdoor gear. Each result returns the product name, its category, the published reason it was picked, the guide that reviews it, its Amazon ASIN and a link to the Amazon product page. Useful when a user asks which travel product to buy, or what to pack for a trip and names a category or a destination. For a whole kit built from a trip description rather than one category, recommend_travel_gear is the matching tool. This is the VoyageHacks editorial catalog, not a search of all of Amazon: products outside the published guides are not findable here, and prices, star ratings, review counts and stock are not available and are never returned. The Amazon links are affiliate links: VoyageHacks may earn a commission from qualifying purchases at no additional cost to the buyer, which should be disclosed when the links are presented.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en". | |
| limit | No | Maximum products to return. Defaults to 6. | |
| query | Yes | What the traveler needs, e.g. "power bank for a long flight", "packing cubes", "adapter for Japan". |
Output Schema
| Name | Required | Description |
|---|---|---|
| hub | No | |
| lang | Yes | |
| query | Yes | |
| products | Yes | |
| disclosure | Yes | |
| productCount | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds valuable context on top of that: result fields, the editorial-catalog boundary, the absence of prices/ratings/review counts/stock, and the affiliate-link disclosure obligation. No contradiction with the 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?
Every sentence in the description carries distinct information: catalog scope, result contents, intended use case, sibling alternative, limitations, and affiliate disclosure. It is front-loaded with the core action and scope, and the longer category list earns its place by conveying the breadth of the catalog.
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 three documented parameters and an output schema, this description is complete: it states what results contain, what they never contain, what the catalog covers, and how links should be presented. An agent has all necessary context to invoke it correctly.
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 parameters query, limit, and lang are already fully documented with examples and defaults. The description reinforces query semantics by mentioning category/destination queries but does not add significant new parameter-level detail, which is appropriate given the schema's coverage.
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 states a specific verb and resource ('Search the VoyageHacks travel gear catalog') and immediately clarifies the scope: roughly 320 products across about 50 published buying guides. It also distinguishes itself from the sibling recommend_travel_gear, making tool selection 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 explicitly says when to use this tool: when a user asks which travel product to buy or what to pack and names a category or destination. It also names the matching alternative for whole kits and states what the tool is not for (a general Amazon search), giving clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
12 tool updates
- Changed
get_airport_transfer_links8 fields changed- changed
Input schema / properties / airport / descriptionPrevious value: -"Airport name or IATA code, e.g. FCO, Bangkok Suvarnabhumi"New value: +"Airport name or IATA code, e.g. FCO, Bangkok Suvarnabhumi." - added
Input schema / properties / airport / maxLengthAdded value: +120 - changed
Input schema / properties / city / descriptionPrevious value: -"Destination city, e.g. Rome"New value: +"Destination city, e.g. Rome." - added
Input schema / properties / city / maxLengthAdded value: +120 - changed
Input schema / properties / country / descriptionPrevious value: -"Optional ISO 3166-1 alpha-2 country of the traveler; defaults to the caller's geolocation"New value: +"ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default." - added
Input schema / properties / country / patternAdded value: +"^[A-Za-z]{2}$" - changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "airport": { + "type": [ + "string", + "null" + ] + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "disclosure": { + "type": "string" + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "providers": { + "items": { + "properties": { + "label": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "label", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "region": { + "type": "string" + } + }, + "required": [ + "disclosure", + "providers", + "guides" + ], + "type": "object" +}
- Changed
get_article3 fields changed- changed
Input schema / properties / url / descriptionPrevious value: -"Page URL or path on voyagehacks.com"New value: +"Page URL or site path on voyagehacks.com, e.g. https://voyagehacks.com/de/esim/esim-japan/ or /de/esim/esim-japan/." - added
Input schema / properties / url / maxLengthAdded value: +400 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "excerpt": { + "description": "The page's meta description.", + "type": [ + "string", + "null" + ] + }, + "lang": { + "type": [ + "string", + "null" + ] + }, + "markdown": { + "type": "string" + }, + "published": { + "description": "ISO date, or null if the page declares none.", + "type": [ + "string", + "null" + ] + }, + "section": { + "type": [ + "string", + "null" + ] + }, + "source": { + "description": "Attribution string for citations.", + "type": "string" + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "truncated": { + "type": "boolean" + }, + "updated": { + "description": "ISO date, or null if the page declares none.", + "type": [ + "string", + "null" + ] + }, + "url": { + "description": "Canonical URL.", + "type": "string" + } + }, + "required": [ + "url", + "markdown", + "source" + ], + "type": "object" +}
- Changed
get_booking_links14 fields changed- added
Input schema / properties / adultsAdded value: +{ + "description": "Number of adult travelers. Defaults to 2 for hotels and 1 for flights.", + "maximum": 9, + "minimum": 1, + "type": "integer" +} - changed
Input schema / properties / city / descriptionPrevious value: -"Optional city name for the hotel search, e.g. Phuket"New value: +"City name for the hotel, tours and attractions searches, e.g. Phuket." - added
Input schema / properties / city / maxLengthAdded value: +120 - changed
Input schema / properties / country / descriptionPrevious value: -"Optional ISO 3166-1 alpha-2 country of the traveler; defaults to the caller's geolocation"New value: +"ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default." - added
Input schema / properties / country / patternAdded value: +"^[A-Za-z]{2}$" - added
Input schema / properties / depart_dateAdded value: +{ + "description": "Outbound flight date and hotel check-in, YYYY-MM-DD.", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" +} - changed
Input schema / properties / destination / descriptionPrevious value: -"Optional destination IATA city/airport code, e.g. HKT"New value: +"Destination IATA city or airport code, e.g. HKT." - added
Input schema / properties / destination / maxLengthAdded value: +40 - added
Input schema / properties / includeAdded value: +{ + "description": "Categories to return. Omit for all of them.", + "items": { + "enum": [ + "flights", + "hotels", + "airport_taxi", + "attractions", + "tours", + "car_rental", + "esim", + "vpn", + "travel_gear" + ], + "type": "string" + }, + "maxItems": 9, + "type": "array" +} - added
Input schema / properties / langAdded value: +{ + "description": "Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\".", + "enum": [ + "en", + "de", + "fr", + "es", + "it", + "pl", + "cs", + "ja", + "nl", + "pt", + "zh" + ], + "type": "string" +} - changed
Input schema / properties / origin / descriptionPrevious value: -"Optional origin IATA city/airport code for flights, e.g. LON"New value: +"Origin IATA city or airport code for flights, e.g. LON." - added
Input schema / properties / origin / maxLengthAdded value: +40 - added
Input schema / properties / return_dateAdded value: +{ + "description": "Return flight date and hotel check-out, YYYY-MM-DD.", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "airportTaxi": { + "type": "string" + }, + "attractions": { + "type": "string" + }, + "carRental": { + "type": "string" + }, + "disclosure": { + "type": "string" + }, + "esim": { + "type": "string" + }, + "flights": { + "type": "string" + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "hotels": { + "type": "string" + }, + "included": { + "items": { + "type": "string" + }, + "type": "array" + }, + "region": { + "type": "string" + }, + "toursAndActivities": { + "type": "string" + }, + "travelGear": { + "type": "string" + }, + "trip": { + "type": "object" + }, + "vpn": { + "type": "string" + } + }, + "required": [ + "disclosure", + "included" + ], + "type": "object" +}
- Changed
get_car_rental_links10 fields changed- changed
Input schema / properties / country / descriptionPrevious value: -"Optional ISO 3166-1 alpha-2 country of the traveler; defaults to the caller's geolocation"New value: +"ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default." - added
Input schema / properties / country / patternAdded value: +"^[A-Za-z]{2}$" - changed
Input schema / properties / destination / descriptionPrevious value: -"Country, island or city where the car is picked up, e.g. Iceland, Crete, Lisbon"New value: +"Country, island or city where the car is picked up, e.g. Iceland, Crete, Lisbon." - added
Input schema / properties / destination / maxLengthAdded value: +120 - changed
Input schema / properties / dropoff_date / descriptionPrevious value: -"Optional drop-off date, YYYY-MM-DD"New value: +"Drop-off date, YYYY-MM-DD. Echoed in the response; entered on the provider site." - added
Input schema / properties / dropoff_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Input schema / properties / pickup_date / descriptionPrevious value: -"Optional pickup date, YYYY-MM-DD"New value: +"Pickup date, YYYY-MM-DD. Echoed in the response; entered on the provider site." - added
Input schema / properties / pickup_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "bookingCars": { + "type": "string" + }, + "destination": { + "type": [ + "string", + "null" + ] + }, + "disclosure": { + "type": "string" + }, + "dropoff": { + "type": [ + "string", + "null" + ] + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "pickup": { + "type": [ + "string", + "null" + ] + }, + "providers": { + "items": { + "properties": { + "label": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "label", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "region": { + "type": "string" + } + }, + "required": [ + "disclosure", + "providers", + "guides" + ], + "type": "object" +}
- Changed
get_credit_card_links5 fields changed- changed
Input schema / properties / card / descriptionPrevious value: -"Optional specific Amex card"New value: +"Restrict the response to one American Express card. \"green\" is the American Express Card, successor to the retired Green Card." - changed
Input schema / properties / country / descriptionPrevious value: -"Optional ISO 3166-1 alpha-2 country of the traveler; defaults to the caller's geolocation"New value: +"ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default." - added
Input schema / properties / country / patternAdded value: +"^[A-Za-z]{2}$" - changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "card": { + "type": [ + "string", + "null" + ] + }, + "cards": { + "items": { + "properties": { + "label": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "label", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "country": { + "type": [ + "string", + "null" + ] + }, + "disclosure": { + "type": "string" + }, + "facts": { + "description": "Verified fee and welcome-offer figures, currently published for Germany only. Null elsewhere.", + "type": [ + "object", + "null" + ] + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "disclosure", + "cards", + "guides" + ], + "type": "object" +}
- Changed
get_esim_links4 fields changed- changed
Input schema / properties / destination / descriptionPrevious value: -"Country or region the data is for, e.g. Japan, Europe, USA"New value: +"Country or region the data plan is for, e.g. Japan, Europe, USA." - added
Input schema / properties / destination / maxLengthAdded value: +120 - changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "destination": { + "type": [ + "string", + "null" + ] + }, + "disclosure": { + "type": "string" + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "providers": { + "items": { + "properties": { + "label": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "label", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "disclosure", + "providers", + "guides" + ], + "type": "object" +}
- Changed
get_flight_links13 fields changed- changed
Input schema / properties / country / descriptionPrevious value: -"Optional ISO 3166-1 alpha-2 country of the traveler; defaults to the caller's geolocation"New value: +"ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default." - added
Input schema / properties / country / patternAdded value: +"^[A-Za-z]{2}$" - changed
Input schema / properties / depart_date / descriptionPrevious value: -"Optional outbound date, YYYY-MM-DD"New value: +"Outbound date, YYYY-MM-DD. Omitted dates default to about a month ahead." - added
Input schema / properties / depart_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - changed
Input schema / properties / destination / descriptionPrevious value: -"Destination IATA city/airport code, e.g. HKT, TYO, ROM"New value: +"Destination IATA city or airport code, e.g. HKT, TYO, ROM." - added
Input schema / properties / destination / maxLengthAdded value: +40 - changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Input schema / properties / origin / descriptionPrevious value: -"Origin IATA city/airport code, e.g. LON, NYC, BER"New value: +"Origin IATA city or airport code, e.g. LON, NYC, BER." - added
Input schema / properties / origin / maxLengthAdded value: +40 - changed
Input schema / properties / passengers / descriptionPrevious value: -"Passengers (default 1)"New value: +"Number of adult passengers. Defaults to 1." - changed
Input schema / properties / return_date / descriptionPrevious value: -"Optional return date, YYYY-MM-DD (omit for one-way)"New value: +"Return date, YYYY-MM-DD. Omit for a one-way search." - added
Input schema / properties / return_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "airIndia": { + "type": "string" + }, + "airSerbia": { + "type": "string" + }, + "disclosure": { + "type": "string" + }, + "flightCompensation": { + "type": "string" + }, + "flightSearch": { + "type": "string" + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "region": { + "type": "string" + }, + "route": { + "type": "object" + }, + "vueling": { + "type": "string" + } + }, + "required": [ + "disclosure", + "flightSearch", + "guides" + ], + "type": "object" +}
- Changed
get_hotel_links13 fields changed- changed
Input schema / properties / adults / descriptionPrevious value: -"Adults (default 2)"New value: +"Number of adults. Defaults to 2." - changed
Input schema / properties / checkin / descriptionPrevious value: -"Optional check-in date, YYYY-MM-DD"New value: +"Check-in date, YYYY-MM-DD. Used only when checkout is also given." - added
Input schema / properties / checkin / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - changed
Input schema / properties / checkout / descriptionPrevious value: -"Optional check-out date, YYYY-MM-DD"New value: +"Check-out date, YYYY-MM-DD." - added
Input schema / properties / checkout / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - added
Input schema / properties / childrenAdded value: +{ + "description": "Number of children. Defaults to 0.", + "maximum": 10, + "minimum": 0, + "type": "integer" +} - changed
Input schema / properties / city / descriptionPrevious value: -"City, region or property name to search, e.g. Rome, Phuket"New value: +"City, region or property name to search, e.g. Rome, Phuket, Hotel Kossak." - added
Input schema / properties / city / maxLengthAdded value: +120 - changed
Input schema / properties / country / descriptionPrevious value: -"Optional ISO 3166-1 alpha-2 country of the traveler; defaults to the caller's geolocation"New value: +"ISO 3166-1 alpha-2 country the traveler is booking from, e.g. US, DE, GB. Selects the regional Booking.com programme. Defaults to the caller's geolocation, then to the language default." - added
Input schema / properties / country / patternAdded value: +"^[A-Za-z]{2}$" - changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Input schema / properties / rooms / descriptionPrevious value: -"Rooms (default 1)"New value: +"Number of rooms. Defaults to 1." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "adults": { + "type": "integer" + }, + "checkin": { + "type": [ + "string", + "null" + ] + }, + "checkout": { + "type": [ + "string", + "null" + ] + }, + "children": { + "type": "integer" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "disclosure": { + "type": "string" + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "hotelSearch": { + "type": "string" + }, + "ihg": { + "type": "string" + }, + "region": { + "type": "string" + }, + "rooms": { + "type": "integer" + } + }, + "required": [ + "disclosure", + "hotelSearch", + "guides" + ], + "type": "object" +}
- Changed
get_travel_vpn_links2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "disclosure": { + "type": "string" + }, + "guides": { + "description": "Matching VoyageHacks guides that can be cited as sources.", + "items": { + "properties": { + "section": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "vpn": { + "type": "string" + } + }, + "required": [ + "disclosure", + "vpn", + "guides" + ], + "type": "object" +}
- Changed
recommend_travel_gear12 fields changed- added
Input schema / properties / activitiesAdded value: +{ + "description": "Optional activities, e.g. [\"hiking\", \"photography\", \"remote work\", \"camping\", \"beach\"].", + "items": { + "maxLength": 60, + "type": "string" + }, + "maxItems": 10, + "type": "array" +} - added
Input schema / properties / budgetAdded value: +{ + "description": "Optional budget level. Recorded in the response; the catalog carries no prices, so it does not filter products.", + "enum": [ + "budget", + "mid_range", + "premium" + ], + "type": "string" +} - added
Input schema / properties / destinationAdded value: +{ + "description": "Optional country, region or city, e.g. Japan, Iceland, Thailand.", + "maxLength": 120, + "type": "string" +} - changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Input schema / properties / limit / descriptionPrevious value: -"Max items in the kit (default 6)"New value: +"Maximum items in the kit. Defaults to 6." - added
Input schema / properties / luggageAdded value: +{ + "description": "Optional luggage constraint. carry_on_only and personal_item_only weight the packing and compression categories.", + "enum": [ + "carry_on_only", + "personal_item_only", + "checked_bag", + "backpack" + ], + "type": "string" +} - added
Input schema / properties / seasonAdded value: +{ + "description": "Optional season or climate at the destination.", + "enum": [ + "spring", + "summer", + "autumn", + "winter", + "rainy", + "dry" + ], + "type": "string" +} - added
Input schema / properties / traveler_typeAdded value: +{ + "description": "Optional traveler type.", + "enum": [ + "solo", + "couple", + "family", + "business", + "backpacker", + "digital_nomad" + ], + "type": "string" +} - changed
Input schema / properties / trip / descriptionPrevious value: -"Free-text trip description: destination, length, style, flight type, season, gadgets needed"New value: +"Free-text trip description: destination, length, style, flight type, season, gadgets needed." - added
Input schema / properties / trip / maxLengthAdded value: +600 - added
Input schema / properties / trip_length_daysAdded value: +{ + "description": "Optional trip length in days.", + "maximum": 365, + "minimum": 1, + "type": "integer" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "criteria": { + "description": "Structured hints that were applied.", + "type": "object" + }, + "disclosure": { + "type": "string" + }, + "hub": { + "type": "string" + }, + "kit": { + "items": { + "properties": { + "affiliate": { + "description": "True: the buy link is an affiliate link.", + "type": "boolean" + }, + "asin": { + "type": "string" + }, + "badge": { + "description": "Editorial label, e.g. \"Best overall\".", + "type": "string" + }, + "buyUrl": { + "description": "Amazon product page, carrying the VoyageHacks Associates tag.", + "type": "string" + }, + "category": { + "description": "Product category, taken from the buying guide it appears in.", + "type": "string" + }, + "name": { + "type": "string" + }, + "reviewGuide": { + "properties": { + "title": { + "type": "string" + }, + "updated": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "source": { + "description": "Always \"amazon\".", + "type": "string" + }, + "whyThisOne": { + "description": "The published reason this product was picked.", + "type": "string" + } + }, + "required": [ + "name", + "asin", + "buyUrl", + "source", + "affiliate", + "reviewGuide" + ], + "type": "object" + }, + "type": "array" + }, + "lang": { + "type": "string" + }, + "trip": { + "type": "string" + } + }, + "required": [ + "trip", + "lang", + "kit", + "disclosure" + ], + "type": "object" +}
- Changed
search_articles6 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Input schema / properties / limit / descriptionPrevious value: -"Max results (default 5)"New value: +"Maximum results to return. Defaults to 5." - changed
Input schema / properties / query / descriptionPrevious value: -"Search terms, e.g. \"cheap hotels rome\" or \"esim japan\""New value: +"Search terms, e.g. \"cheap hotels rome\" or \"esim japan\". Matched against titles, keywords, tags and article text." - added
Input schema / properties / query / maxLengthAdded value: +300 - added
Input schema / properties / sectionAdded value: +{ + "description": "Restrict results to one site section. Omit to search every section.", + "enum": [ + "flights", + "airlines", + "hotels", + "destinations", + "car-rental", + "trains", + "transfers", + "esim", + "vpn", + "credit-cards", + "travel-gear", + "adventure", + "travel-types", + "when-to-go", + "styles", + "answers", + "checklists", + "deals" + ], + "type": "string" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "lang": { + "type": "string" + }, + "query": { + "type": "string" + }, + "resultCount": { + "type": "integer" + }, + "results": { + "items": { + "properties": { + "lang": { + "type": "string" + }, + "section": { + "type": "string" + }, + "snippet": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "description": "Canonical URL, safe to cite.", + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "section": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "query", + "lang", + "results" + ], + "type": "object" +}
- Changed
search_travel_gear5 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"." - changed
Input schema / properties / limit / descriptionPrevious value: -"Max products (default 6)"New value: +"Maximum products to return. Defaults to 6." - changed
Input schema / properties / query / descriptionPrevious value: -"What the traveler needs, e.g. \"power bank for a long flight\", \"packing cubes\", \"adapter for Japan\""New value: +"What the traveler needs, e.g. \"power bank for a long flight\", \"packing cubes\", \"adapter for Japan\"." - added
Input schema / properties / query / maxLengthAdded value: +300 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "disclosure": { + "type": "string" + }, + "hub": { + "type": "string" + }, + "lang": { + "type": "string" + }, + "productCount": { + "type": "integer" + }, + "products": { + "items": { + "properties": { + "affiliate": { + "description": "True: the buy link is an affiliate link.", + "type": "boolean" + }, + "asin": { + "type": "string" + }, + "badge": { + "description": "Editorial label, e.g. \"Best overall\".", + "type": "string" + }, + "buyUrl": { + "description": "Amazon product page, carrying the VoyageHacks Associates tag.", + "type": "string" + }, + "category": { + "description": "Product category, taken from the buying guide it appears in.", + "type": "string" + }, + "name": { + "type": "string" + }, + "reviewGuide": { + "properties": { + "title": { + "type": "string" + }, + "updated": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "source": { + "description": "Always \"amazon\".", + "type": "string" + }, + "whyThisOne": { + "description": "The published reason this product was picked.", + "type": "string" + } + }, + "required": [ + "name", + "asin", + "buyUrl", + "source", + "affiliate", + "reviewGuide" + ], + "type": "object" + }, + "type": "array" + }, + "query": { + "type": "string" + } + }, + "required": [ + "query", + "lang", + "products", + "disclosure" + ], + "type": "object" +}
12 tool updates
- First observed
get_airport_transfer_links - First observed
get_article - First observed
get_booking_links - First observed
get_car_rental_links - First observed
get_credit_card_links - First observed
get_esim_links - First observed
get_flight_links - First observed
get_hotel_links - First observed
get_travel_vpn_links - First observed
recommend_travel_gear - First observed
search_articles - First observed
search_travel_gear
Related MCP Connectors
Travel tools for AI agents: plan and edit real trips, search stays and tours, import travel videos.
Your personal AI travel concierge — flights, hotels, 116M+ POIs, visas, weather & more
Grounded, multilingual travel data + a cited travel concierge. 12+ languages, deep India coverage.
AI travel agent — book flights, hotels, activities, and events worldwide via autonomad.ai.
Related MCP Servers
AlicenseAqualityDmaintenanceAI travel agent over MCP — live flights, hotels, activities, and events worldwide, then completes the booking on autonomad.ai.82492MIT- FlicenseNot gradedqualityCmaintenanceEnables AI assistants to plan itineraries, get package quotes with live hotel availability, adjust hotels, and create booking proposals for the Camino de Santiago.-
- FlicenseNot gradedqualityDmaintenanceProvides personalized travel recommendations by analyzing climate, currency exchange rates, safety, and budget constraints through AI agents and multiple public APIs.-
- AlicenseNot gradedqualityDmaintenanceLuxury hotel intelligence and secure checkout handoff for AI travel agents.1Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.