Skip to main content
Glama

Untap

by io.github.aneduaim
OverviewDiscussionsAdmin

Check a delayed train for Delay Repay

check_train_delay
Read-onlyIdempotent

Checks a late or cancelled train in Great Britain against National Rail’s historic running records and works out Delay Repay. Takes the two stations (names, partial names or three-letter codes), the date and roughly when the train left; the operator, ticket type and price paid are optional. Returns the matched train with scheduled and actual times, the delay at the destination, the operator and its scheme, the amount (or the percentage when no price is given), the claim deadline, a claim pack with the value for each form field, and the details needed to save the claim to an Untap account. When several trains fit, the result lists them, each with a service_id. The records cover roughly the last year and each day appears the day after. They hold direct trains only, so a journey with a change is checked one train at a time. When nothing could be learned, status is data_not_available with delay_known false, a reason, retryable and retry_after_seconds or try_again_on. When National Rail is slow the lookup carries on in the background, and a retry after retry_after_seconds is answered from the cache. No sign-in needed. Nothing is saved to an account. A record of the check, with no name, account or IP address, is kept for a year so answers can be verified.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesStation the person got off at, in the same forms.
dateYesDate of travel. YYYY-MM-DD is best; "25/09/2026", "25 September", "yesterday" and "last Friday" also work.
fromYesStation the person got on at. A name, part of a name or a three-letter code: "Brighton", "Kings Cross", "BTN".
ticketsNoHow many tickets of this price are on the booking, one per passenger. Defaults to 1. The amount is per ticket times this.
operatorNoTrain company if known, as the person says it: "Southern", "GWR", "Avanti". Used to narrow the match.
price_paidNoWhat one ticket cost, in pounds: "£24.50", 24.5 or 17 (read as £17.00). For a season ticket, the price of the whole season. Needed for a cash amount; without it the percentage is returned.
service_idNoThe service_id of a train listed in an earlier result. With it, that train is checked directly.
ticket_typeNoAs printed: "Anytime Return", "Off-Peak Single", "Advance", "Annual Season", "Monthly Season", "Flexi Season". A return halves the single fare the amount is worked from. A season is valued per journey from its length; a season with no length gets no amount.
departure_timeNoRoughly when the train left the first station, UK time: "08:05", "8am", "around 8". Needed to find the train unless service_id is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / price_paid / description
      Previous value: -"What the ticket cost: \"£24.50\", 24.50 or 2450 (pence). For a season ticket, the price of the whole season. Needed for a cash amount; without it the percentage is returned."New value: +"What one ticket cost, in pounds: \"£24.50\", 24.5 or 17 (read as £17.00). For a season ticket, the price of the whole season. Needed for a cash amount; without it the percentage is returned."
    • addedInput schema / properties / tickets
      Added value: +{
+  "anyOf": [
+    {
+      "maximum": 9,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "How many tickets of this price are on the booking, one per passenger. Defaults to 1. The amount is per ticket times this."
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / price_paid / description
      Previous value: -"What the ticket cost: \"£24.50\", 24.50 or 2450 (pence). Needed for a cash amount; without it the percentage is returned."New value: +"What the ticket cost: \"£24.50\", 24.50 or 2450 (pence). For a season ticket, the price of the whole season. Needed for a cash amount; without it the percentage is returned."
    • changedInput schema / properties / ticket_type / description
      Previous value: -"As printed: \"Anytime Return\", \"Off-Peak Single\", \"Advance\", \"Season\". A return halves the single fare the amount is worked from."New value: +"As printed: \"Anytime Return\", \"Off-Peak Single\", \"Advance\", \"Annual Season\", \"Monthly Season\", \"Flexi Season\". A return halves the single fare the amount is worked from. A season is valued per journey from its length; a season with no length gets no amount."
  3. Changed2 schema fields changed
    • changedInput schema / properties / departure_time / description
      Previous value: -"Roughly when the train left the first station, UK time: \"08:05\", \"8am\", \"around 8\". Leave out if unknown and Untap lists the day’s trains to choose from."New value: +"Roughly when the train left the first station, UK time: \"08:05\", \"8am\", \"around 8\". Needed to find the train unless service_id is given."
    • changedInput schema / properties / service_id / description
      Previous value: -"The service_id of a candidate returned by an earlier call, to confirm which train it was."New value: +"The service_id of a train listed in an earlier result. With it, that train is checked directly."
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Despite annotations already covering the safety profile (readOnly, idempotent, openWorld), the description adds substantial behavioral detail: data coverage (last year, next-day, direct trains only), the data_not_available status shape with retryable/retry_after_seconds, background lookup with cached retries, and the privacy/retention note. This is rich context beyond the structured fields.

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?

The purpose and inputs lead, with the return/error behavior following, so it is front-loaded. It is dense and runs long, but most sentences (retry semantics, coverage limits, retention) carry real information for a 9-parameter tool.

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?

There is no output schema, so the description carries the full burden and delivers: it enumerates the returned fields (times, delay, operator, amount, deadline, claim pack, save details) and the multi-match service_id behavior. An agent has everything needed to call and interpret it.

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 coverage is 100%, so the schema already documents every parameter including formats and the amount-vs-percentage behavior. The description's parameter recap largely restates the schema, so the baseline of 3 is appropriate rather than a higher score.

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?

The description names a specific verb (checks a late or cancelled train) and resource (Great Britain National Rail running records), and states the outcome (works out Delay Repay). This clearly separates it from siblings like check_flight_compensation and get_delay_repay_rules.

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

Usage Guidelines4/5

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

It gives strong context: stations accept names/partial/codes, service_id lets you check a specific train, changes must be checked one train at a time, and no sign-in is needed. It never explicitly names an alternative tool or a when-not-to-use condition, so it falls short of full routing guidance.

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

All Untap 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