Skip to main content
Glama

Tours on sale

list_tours
Read-onlyIdempotent

List the tours Follow On Tours currently has published. Use this to find out what is on sale before asking about a specific tour. Returns only published tours — the same set a visitor can see on the website — in tours, each with its page url, dates, nights, fixtures (the matches), hotels, included, notIncluded, optionalExtras and onRequest. What a tour includes comes in three layers, and every tour is different: included is what the price covers; optionalExtras are add-ons the traveller can choose in the booker, with their price and whether it is per person or per booking; onRequest is everything else, with examples. If a traveller wants something not listed, never say it is not available: ask what else they would like to do and use request_quote. Every tour can also be built around the traveller (buildYourOwn): other dates, more nights or another hotel, through request_quote. When priceBasis is "per person", fromPricePerPerson (two sharing) and singleOccupancyFromPrice are the lowest selling prices shown on the tour page, in currency: quote them as "from" prices, exactly as given, never as a final price for a particular group, and say what one price covers from pricedPer (on a multi-match tour it is one match, not the whole series). When priceBasis is "not yet priced", say the price is on request and never estimate one. Every trip in every list carries status (bookable, on_request, register_interest or sold_out) and availability (available, limited, sold_out or on_request); limited means some ticket categories or hotels have already sold out. Never state or guess how many rooms, seats or tickets are left. The paymentTerms on each tour give the deposit (or "Confirmed on the quote" when none is set), when the balance is due and the date, quoted exactly; on a tour with several matches each match has its own balance date in balanceDueByMatch (90 days before the traveller arrives for that match), so give the one for their match; a match that says balanceDue: "Full price at booking" has no balance date left and no deposit option, so the full price is paid at booking; never add terms that are not there. Tours Follow On Tours is quoting now but builds to order (no published programme, no online checkout) come back in bespokeTours: they ARE available, quoted on enquiry. Trips available now but sold on request (no fixed dates, no published price, quoted for each group; e.g. golf in Argentina) come back in onRequestTrips: offer them, call get_trip_details with the trip’s slug for its full page text, and use request_quote to ask for a quote. Tours that are announced but NOT yet on sale come back separately in holdingTours: they cannot be booked and their schedules are not confirmed, so never present one as bookable. For a coming-soon tour’s full public page text (intro, sections, FAQs), which is safe to quote, call get_trip_details with its slug. For the golf trips use list_golf_trips.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish a safe read-only, idempotent operation, but the description adds substantial behavioral context: what categories are returned, how bespokeTours/onRequestTrips/holdingTours differ, how status and availability should be interpreted, and strict rules against guessing inventory or prices.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and usage guidance are front-loaded, and much of the detailed output and pricing policy is necessary because there is no output schema. However, it is a dense, unbroken paragraph with some marginally useful phrasing such as 'and every tour is different' and 'with examples'; headings or bullets would improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and a complex domain with multiple tour categories, the description is remarkably complete. It explains return fields, category meanings, availability and pricing semantics, payment-term handling, and the relevant sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero input parameters and an empty schema, so there is no input semantics for the description to compensate for. The baseline for a no-parameter tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: listing published tours. It also fixes the scope ('currently has published', 'only published tours') and distinguishes the result from golf trips and full trip pages by naming list_golf_trips and get_trip_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use this before asking about a specific tour, routes unlisted traveller requests to request_quote, routes tour page text to get_trip_details, and routes golf trips to list_golf_trips. It also explains when tours should not be presented as bookable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources