Skip to main content
Glama
Sign In

cricket-travel

by com.followontours
OverviewDiscussionsAdmin

Request a quote

request_quote

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.

Input Schema

NameRequiredDescriptionDefault
nameYesThe traveller's full name.
tripYesThe trip name or page URL from list_tours / list_golf_trips, or a short description.
emailYesThe traveller's own email address. The confirmation goes here.
notesNoAnything else: hotel preference, extras.
phoneNo
nightsNoHow many nights away, if the traveller has said.
assistantNoYour own name, e.g. "Claude".
partySizeNoHow many people are travelling.
budgetBandNoThe traveller's rough budget per person, only if they have said. Never a price from Follow On Tours.
preferredDatesNoDates or matches, in the traveller's words.
groundPreferenceNoWhich grounds, matches or courses matter most, in the traveller's words.

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. Changed4 schema fields changed
    • addedInput schema / properties / budgetBand
      Added 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"
+}
    • addedInput schema / properties / groundPreference
      Added value: +{
+  "description": "Which grounds, matches or courses matter most, in the traveller's words.",
+  "maxLength": 200,
+  "type": "string"
+}
    • addedInput schema / properties / nights
      Added value: +{
+  "description": "How many nights away, if the traveller has said.",
+  "maximum": 60,
+  "minimum": 1,
+  "type": "integer"
+}
    • changedInput schema / properties / notes / description
      Previous value: -"Anything else: hotel preference, budget, extras."New value: +"Anything else: hotel preference, extras."
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All cricket-travel 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