Bespoke cricket and golf travel. Tour operator and package organiser — you contract with us and we take payment. ABTOT bonded (5718). Not a broker. Darren Gough MBE ambassador & shareholder. Public MCP: list tours (incl. holding), destinations, golf trips, Cape Town experiences, financial protection. Expanding into wider sports travel. No authentication required
Scored across 9 tools
Most tools map to distinct resources (tours, golf trips, destinations, Cape Town experiences, trip details, price, quote). The main overlap is get_about, whose description explicitly claims 'our financial protection', versus the dedicated get_protection tool, and there is mild boundary friction between list_tours/list_golf_trips/get_trip_details. The long descriptions do steer an agent to the right tool, so misselection is unlikely but not impossible.
Every tool follows a clean verb_noun snake_case pattern: get_about, get_price, get_protection, get_trip_details, list_*, request_quote. The get_/list_/request_ prefixes map predictably onto retrieve/list/submit semantics.
Nine tools is well within the sweet spot and each one earns its place: four list tools scoped to genuinely different inventory (published tours, golf trips, destinations, Cape Town experiences), three getters, and one mutation (request_quote). No redundant or vestigial tools.
The research-to-enquiry lifecycle is covered end to end: browse inventory, drill into a trip, get an indicative price, ask for a quote, plus about/protection context. Gaps are minor — there is no search or filter tool across tours/destinations, and no way to check the status of a submitted enquiry, but the enquiry model (email confirmation, no online booking) makes the latter defensible.
Get information about Follow On Tours — who we are, what we sell (bespoke cricket, golf, rugby, polo and playing tours), our experience, our financial protection, and how the service works. Use this when someone asks who Follow On Tours is, whether they cover a sport or destination, or how the service operates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds content scope (the topics returned), which is useful, but says nothing about the shape of the response (free-form text vs structured). With no output schema, a brief note on return format would have raised this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first defines scope by enumerating covered topics, the second gives usage triggers. Front-loaded with the resource name and zero 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 zero-parameter informational tool with annotations covering safety and no output schema, the description gives an agent enough to decide to call it and to know roughly what content it yields. The only missing piece is any indication of response format, which matters slightly more here since there is no output schema.
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?
Zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly does not waste words on parameter explanation.
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 (Get information about) and resource (Follow On Tours) and enumerates the covered topics — who we are, sports sold, experience, financial protection, how the service works. The scope is clearly an 'about us' tool rather than a listing tool like list_tours or list_destinations, though the mention of 'financial protection' overlaps with the sibling get_protection and is not disambiguated.
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?
Explicitly says when to use it: 'when someone asks who Follow On Tours is, whether they cover a sport or destination, or how the service operates.' That is a clear trigger set. It does not name an alternative or exclusion — most notably it never says to prefer get_protection for protection details, despite overlapping with that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an indicative price for a published tour from list_tours (one with status "bookable"), for a number of adults, two sharing a room or each in a single room. It uses the same engine as the Follow On Tours website checkout, for the cheapest available ticket and room, and returns the total and the price per person in the tour currency, with the hotel, ticket and nights it is based on, the day the traveller arrives for that match and the date the balance is due. When that date has already passed it returns balanceDue: "Full price at booking" and no date: there is no deposit option for that match, so never offer one. Quote it exactly as returned, as an indicative price: nothing is held or booked, and the price on the traveller’s own quote is the one that applies. It takes no personal details and sends nothing. For another hotel, extra nights, breakfast, transfers, or any tour priced on request, use request_quote.
| Name | Required | Description | Default |
|---|---|---|---|
| tour | Yes | The tour slug or name from list_tours. | |
| match | No | On a tour with several matches (e.g. a five-Test series), which match or venue, in the traveller’s words: a city, a ground or its nickname (the MCG, Chepauk), or “first”, “fifth”, “the last Test”. If it fits more than one match, the reply says so: ask the traveller which. | |
| adults | Yes | How many adults are travelling. | |
| roomType | Yes | "sharing" = two to a room; "single" = each traveller in their own room. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, it discloses substantive behavior: it uses the same engine as the website checkout, returns cheapest available ticket/room, holds or books nothing, takes no personal details, and sends nothing. It also documents the specific edge case where balance has passed (`balanceDue: "Full price at booking"`, no deposit option) and instructs quoting exactly as returned.
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?
Front-loaded with purpose and scope, then return shape and edge case; every sentence contributes. It is on the long side, but the length is justified by the behavioral and quoting caveats rather than padding.
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 no output schema, the description carries the burden of describing returns and does so thoroughly: total and per-person price, tour currency, hotel, ticket, nights, arrival day, and balance due date, including the deposit edge case. Nothing an agent needs to call or interpret the result 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%, so the schema already documents tour, match, adults, and roomType fully. The description restates the adults and sharing/single semantics but adds no format or matching detail beyond what the schema's parameter descriptions already provide, so 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?
States a specific verb and resource ('Get an indicative price for a published tour') plus the exact source of the tour (list_tours, status 'bookable'). It also names the sibling (request_quote) it is not, so an agent can distinguish it from alternatives without opening schemas.
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?
Explicitly scopes usage to published/bookable tours from list_tours with adults and room sharing/single, and gives the exclusion condition for request_quote (another hotel, extra nights, breakfast, transfers, or any tour priced on request). The balance-due edge case instructions ('never offer a deposit') add clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Follow On Tours' financial protection statement and its position in the contract — that it is the tour operator and package organiser, bonded through ABTOT. Use this when asked who the customer contracts with, who takes payment, whether the trip is financially protected, or about ATOL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds substantive behavioral context beyond that: what domain the answer comes from (contract position, ABTOT bond, ATOL), which tells the agent what kind of answer to expect from this fixed lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is returned, then the invocation triggers. Every clause carries information — resource, source domain, and use cases — 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 zero-parameter, no-output-schema lookup, the description supplies what an agent needs: the topic covered, the authoritative facts behind it, and the questions it answers. Nothing required to call it correctly 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter hints are present.
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 ('Get Follow On Tours' financial protection statement and its position in the contract') and even names the underlying fact (ABTOT bonding). It does not explicitly differentiate from the sibling get_about, which could plausibly be mistaken for a source of the same company-level facts, so it falls just short of 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?
Provides an explicit trigger list: who the customer contracts with, who takes payment, whether the trip is financially protected, or ATOL. That is clear routing context with no ambiguity, though it gives no exclusion telling the agent when to prefer get_about instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full public page text (intro, sections and FAQs) of one trip from list_tours or list_golf_trips, by its slug: a trip sold on request (onRequestTrips) or a coming-soon tour (holdingTours). The text is the trip's public page and is safe to quote. It returns the trip's name, url and status with the text; keep to what the status says: an on_request trip is quoted on request with no published price, so use request_quote, and a register_interest tour is not yet on sale and cannot be booked. Never add prices, dates or availability that are not in the text. For tours on sale use list_tours, which already carries their full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The trip’s `slug` exactly as list_tours or list_golf_trips gives it, e.g. "golf-in-argentina". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds substantive context: it returns name, url and status with the text, explains status-dependent quoting/bookability, and warns not to invent prices, dates or availability. This goes well beyond the annotations and clarifies safe quoting.
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 action and stays focused on relevant scope/status rules. It is somewhat dense with multiple status names and constraints, but each sentence contributes useful guidance rather than repetition.
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 no output schema, the description still explains the returned fields (name, url, status plus page text) and how status affects use. It also covers source, alternatives, and quoting constraints, making it complete for a one-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single slug parameter has 100% schema description coverage, including the exact-source wording, so the schema already carries the parameter meaning. The description reinforces the source list but does not add new syntax or validation details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get the full public page text') and resource ('one trip'), and explicitly scopes it to slugs from list_tours or list_golf_trips. It also distinguishes this tool from list_tours for on-sale tours, so an agent can identify its role 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?
It gives explicit conditions for use: trips sold on request or coming-soon tours, by slug from the list tools. It names alternatives and exclusions: use request_quote for on_request trips, list_tours for on-sale tours, and register_interest tours cannot be booked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Cape Town day experiences Follow On Tours arranges — city and peninsula tours, the Winelands, whale watching, Marine Big 5, shark cage diving, safari and a scenic helicopter flight — with what each day covers and what is included. Use this for any Cape Town or South Africa enquiry. Enquiry-led: no price is quoted and nothing is charged online. Follow On Tours also builds a full Cape Town week around these on request.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful business context beyond those annotations: the interaction is enquiry-led, no price is quoted, and nothing is charged online. It does not describe the response shape, though no output schema exists.
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 resource and its coverage, followed by the key usage and commercial-model constraints. It is mostly efficient, though the final sentence about building a full Cape Town week is somewhat promotional and could be considered extra context rather than essential invocation information.
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 zero-parameter list tool with no output schema, the description is largely complete: it explains what is listed, what detail each entry covers, and the enquiry-led commercial model. It could be slightly more complete by clarifying how this list relates to the broader list_tours sibling, but nothing critical is missing for correct 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?
The tool has zero input parameters, so the baseline is 4. The description appropriately spends no space explaining parameters and instead clarifies the tool's scope and inquiry model.
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 names a specific verb and resource: list Cape Town day experiences arranged by Follow On Tours, and it enumerates the experience categories (city tours, Winelands, whale watching, safari, helicopter flight). It is clear on its own, but it never explicitly distinguishes itself from siblings such as list_tours or list_destinations, so the agent must infer the geographic specialization.
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 a clear usage condition: 'Use this for any Cape Town or South Africa enquiry.' It also clarifies the enquiry-led model with no online pricing or charging, which helps separate it from get_price and request_quote. It does not, however, state when not to use it or name the specific alternative sibling to use outside Cape Town enquiries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where Follow On Tours goes and what it sells there. When a country has a tour on sale (onSale, with its link and dates), lead with that tour, then offer to build a trip around the traveller (buildYourOwn); a country with nothing on sale is built to order. Returns the sport hubs (cricket, golf, rugby, playing tours) in sportHubs, every live country page with its sport pages (cricket, golf, rugby, polo, playing tours and more) in countries, and the cricket grounds each cricket trip is built around in destinations. Apart from the tours in onSale, everything here is built to order, so no price or departure date applies: use list_tours for prices and details of what is on sale or quoted on request, and list_golf_trips for golf. Use this when asked where Follow On Tours goes, or whether they cover a sport, a country or a ground.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent, closed-world read, so the description is free to add domain context — and it does: the onSale vs buildYourOwn distinction, and the fact that apart from onSale nothing carries a price or departure date. That's exactly the kind of non-obvious behavioral fact annotations cannot convey.
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?
Front-loaded with the one-line purpose, and the length is largely justified because there is no output schema to carry the return-value documentation. It loses a point for redundancy: the sport list '(cricket, golf, rugby, playing tours)' is enumerated twice and the middle sentence is a long multi-clause run that is harder to parse than it needs to be.
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 zero parameters, no output schema and no nested objects, the description carries the full burden of explaining what comes back — and it does, naming the onSale, buildYourOwn, sportHubs, countries and destinations keys plus the sport coverage within countries. Nothing an agent needs before calling 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?
The tool takes no parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description instead spends its words on return structure, which is the right allocation.
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 ('List where Follow On Tours goes and what it sells there') and immediately distinguishes itself from siblings by naming list_tours and list_golf_trips as the places to go for prices and golf. An agent can identify this as the catalogue/coverage tool without opening any 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?
Explicit trigger is given: 'Use this when asked where Follow On Tours goes, or whether they cover a sport, a country or a ground.' It also states the complementary case — use list_tours for prices and details, list_golf_trips for golf — so the boundary between this tool and its siblings is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Follow On Tours' golf trips — the Trump portfolio venues, with the courses played, the hotel, nights, rounds and maximum group size, and a link to each trip's page. Use this for any golf enquiry. No payment is taken online. Most are priced on request; a set-price week (such as Sri Lanka) carries dates and per-person prices in GBP, which are the prices on its public page and may be quoted exactly as given, plus included, notIncluded and paymentTerms (the deposit and the balance date), also quoted exactly as given; never add terms that are not there. Golf trips sold on request with no fixed dates (e.g. golf in Argentina) come back in onRequestTrips; call get_trip_details with the trip's slug for its full page text, and use request_quote for them. A set-price week and its country's bespoke golf (e.g. Legends & Paradise Golf Premier and Golf in Sri Lanka) are two different trips: the week has set dates, a set price and a set programme; the bespoke trip is any dates, any length and any courses, quoted on request. Offer the one that fits and mention the other (alsoBespoke on the week, alsoBookable on the bespoke trip). Golf trips are separate from the cricket tours in list_tours.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations it discloses commercial behavior the annotations cannot: no payment taken online, most trips priced on request, and a hard constraint never to add payment terms that aren't present. It also reveals the response shape (`onRequestTrips`, `dates`, `prices` in GBP, `included`/`notIncluded`/`paymentTerms`). Minor gap: no note on result volume or ordering.
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?
Purpose is front-loaded and every clause is substantive, but the body is one long run-on paragraph chaining pricing, response fields and trip-type distinctions. The quoting constraint is stated twice ("may be quoted exactly as given" then "also quoted exactly as given; never add terms"), and separate concerns would read better as short sentences.
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 no output schema and zero parameters, the description carries the full burden and meets it: it describes the fields returned for both set-price weeks and on-request trips, the currency, and the quote-handling rules. An agent can call this and interpret the result without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4 and there is nothing to disambiguate. The description instead spends its detail budget on the shape of the returned trip objects, which is useful but doesn't change the parameter score.
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?
Opens with a specific verb and resource ("List Follow On Tours' golf trips") and enumerates what each entry contains — courses, hotel, nights, rounds, max group size, page link. It also triangulates against siblings by stating that golf trips are separate from the cricket tours in list_tours.
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?
Explicit routing: "Use this for any golf enquiry", then it names alternatives with conditions — get_trip_details with the slug for a full page, request_quote for on-request trips, and list_tours for cricket. It also explains how to choose between a set-price week and a bespoke trip and to cross-mention the other via `alsoBespoke`/`alsoBookable`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Ask Follow On Tours for a quote on a traveller's behalf. Use after you have found a suitable trip with list_tours or list_golf_trips (or for any other trip — describe it in trip). Follow On Tours emails the traveller to confirm the request is theirs; nothing reaches Follow On Tours, and nothing is booked or charged, until the traveller taps the link in that email. Only send details the traveller has given you and agreed to share. It returns an enquiry reference (FOT-E-YY-NNNN) to give the traveller. This tool never returns a price: quotes come from Follow On Tours directly.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The traveller's full name. | |
| trip | Yes | The trip name or page URL from list_tours / list_golf_trips, or a short description. | |
| Yes | The traveller's own email address. The confirmation goes here. | ||
| notes | No | Anything else: hotel preference, extras. | |
| phone | No | ||
| nights | No | How many nights away, if the traveller has said. | |
| assistant | No | Your own name, e.g. "Claude". | |
| partySize | No | How many people are travelling. | |
| budgetBand | No | The traveller's rough budget per person, only if they have said. Never a price from Follow On Tours. | |
| preferredDates | No | Dates or matches, in the traveller's words. | |
| groundPreference | No | Which grounds, matches or courses matter most, in the traveller's words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false): it describes the double opt-in flow, that nothing reaches Follow On Tours and nothing is booked or charged until the traveller clicks the emailed link, and that no price is ever returned. That is precisely the side-effect reality an agent needs before firing a mutation.
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?
Five tight sentences, front-loaded with purpose then sequencing, then the consent/confirmation caveat, then the return value. No filler and no repetition of annotation or 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 no output schema and 11 parameters, the description still covers what an agent most needs: the async confirmation flow, the absence of a price in the response, and the concrete return artifact (FOT-E-YY-NNNN reference to hand the traveller). Nothing material 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 91%, so the baseline would be 3, but the description adds a global consent constraint on all submitted fields and widens `trip` to arbitrary trips ('or for any other trip — describe it in `trip`'). It also pre-empts the budgetBand confusion by clarifying it is the traveller's stated budget, not a returned price.
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 (request a quote) on a named resource (Follow On Tours trip enquiry) on a traveller's behalf, and explicitly distinguishes itself from list_tours/list_golf_trips and (implicitly) get_price by noting it 'never returns a price'. An agent can route correctly 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?
Gives an explicit trigger ('Use after you have found a suitable trip with list_tours or list_golf_trips'), a catch-all for anything else via the `trip` field, and a consent precondition ('Only send details the traveller has given you and agreed to share'). Alternatives and the condition selecting them are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_trip_detailsget_about1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_price1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_protection1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_cape_town_experiences1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_destinations1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_golf_trips1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_tours1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"request_quote1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_price1 field changedInput schema / properties / match / descriptionPrevious value: -"On a tour with several matches (e.g. a five-Test series), which match or venue, in the traveller’s words."New value: +"On a tour with several matches (e.g. a five-Test series), which match or venue, in the traveller’s words: a city, a ground or its nickname (the MCG, Chepauk), or “first”, “fifth”, “the last Test”. If it fits more than one match, the reply says so: ask the traveller which."get_pricerequest_quote4 fields changedInput schema / properties / budgetBandAdded value: +{
+ "description": "The traveller's rough budget per person, only if they have said. Never a price from Follow On Tours.",
+ "enum": [
+ "Under £2,000 per person",
+ "£2,000 to £4,000 per person",
+ "£4,000 to £7,000 per person",
+ "Over £7,000 per person"
+ ],
+ "type": "string"
+}Input schema / properties / groundPreferenceAdded value: +{
+ "description": "Which grounds, matches or courses matter most, in the traveller's words.",
+ "maxLength": 200,
+ "type": "string"
+}Input schema / properties / nightsAdded value: +{
+ "description": "How many nights away, if the traveller has said.",
+ "maximum": 60,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / notes / descriptionPrevious value: -"Anything else: hotel preference, budget, extras."New value: +"Anything else: hotel preference, extras."request_quotelist_destinationsget_protectionlist_cape_town_experienceslist_golf_tripslist_toursAggregated travel MCP — flights, tours, activities, price checks, visas, and more.
10-sport calendar MCP — football, F1, tennis, cricket, rugby, golf, polo, sailing, horse racing.
Manage Frontpage websites, CRM, email, Booking, support and analytics with consented MCP tools.
Read-only MCP for Sparkling Tracks European tours: packages, itineraries, pricing, contacts.
Add one secure layer between your agents and this server.
