Skip to main content
Glama
Sign In

Follow On Tours

by com.followontours
OverviewDiscussionsAdmin

Price a tour

get_price
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
tourYesThe tour slug or name from list_tours.
matchNoOn 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.
adultsYesHow many adults are travelling.
roomTypeYes"sharing" = two to a room; "single" = each traveller in their own room.

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. Changed1 schema field changed
    • changedInput schema / properties / match / description
      Previous 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."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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

Schema description coverage is 100%, so the schema 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Follow On Tours toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources