Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_linesA

Every line Tifa records, with its id, name and mode (tube, elizabeth-line, overground or dlr) and the lines it shares track with. The ids are what line_status, disruptions and period_stats take.

current_statusA

The status of every line right now, refreshed from TfL each minute: status text, worst severity, TfL's reasons, whether it is good service and whether a problem is live or planned works; lines with live problems first, then planned works, then good service. Also the disruptions open now (with their start times and causes), the time of the last poll, and stale: true when there has been no poll for over 5 minutes (or the history cannot be read), so the status may be out of date.

line_statusA

One line in depth: its disruptions open now; the number of disruptions, minutes disrupted and share of watched time disrupted over the last 24 hours, 7, 30 and 90 days; its latest disruptions with TfL's reasons and their causes; and the London hours of the day at which its unplanned disruptions start.

disruptionsA

Recorded disruptions overlapping a time range (default: the 30 days to now; at most 366 days), oldest first. One row per spell of one severity on one line: start, end (null while it is still going on), minutes, severity, status text, category, planned or not, cause and TfL's reason, and whether the end is estimated (recording was paused). Filter by line, category, cause and planned. total is how many match; when next_cursor is not null, call again with it (and the same other arguments) for the next page.

period_statsA

Figures for a period, for the network or one line: watched coverage, share of time with good service, unplanned and planned disruption counts, line-time disrupted, the change against the period before (when both were at least 80% watched), the most disrupted line, the longest unplanned disruption, the busiest day, the top causes, per-day (or per-week) bins and a per-line table. period names the period and gives prev and next: the end to pass for the period before or after. Unlike the other tools, times here (t0, t1, p0, starts and ends, bins, unwatched spans) are epoch seconds (UTC) as numbers; only period.first is ISO 8601.

coverageA

When Tifa was watching, over a time range (default: the 7 days to now; at most 90 days): the spans each source covered, the share of the range watched, the gaps nothing watched, and per UTC day the polls recorded (of 1440) and the polls that failed. Check it before reading a quiet period as a good one.

causesA

The causes Tifa puts disruptions down to (read from TfL's reason text), as codes with labels, in the order the rules are tried. The codes are what disruptions takes as cause; a disruption with a null cause is unknown (cause=unknown finds those).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 7 tools

Disambiguation4/5

Each tool has a distinct scope: list_lines and causes are reference lookups, current_status is a network-wide now snapshot, line_status is a per-line deep dive, disruptions is a paged record query, and period_stats/coverage are aggregate analytics. The main risk is overlap between line_status (which includes recent disruptions and per-line counts) and period_stats (which can also produce a per-line table), plus the near-pair naming current_status vs line_status. Descriptions do enough to steer an agent, but the boundary between per-line stats and period stats requires careful reading.

Naming Consistency3/5

All names are lowercase snake_case, which is consistent, but the grammatical pattern is mixed: list_lines is verb_noun, current_status is adjective_noun, line_status is noun_noun, and disruptions/coverage/causes are bare nouns. The verb-style tools imply actions while the noun-style ones are queries, so an agent cannot infer the calling convention from the name alone. Still readable and domain-conventional.

Tool Count5/5

Seven tools is well within the ideal range for a single-domain read-only analytics server. Each one earns its place: two reference lookups, one live snapshot, one per-line detail, one raw record query, one period aggregation and one data-quality checker. No obvious redundancy or filler.

Completeness4/5

The surface covers the lifecycle of observed disruption data well: enumerating lines and causes, live status, historical records with filtering and pagination, period comparisons, and coverage/staleness checks. Minor gaps remain — there is no way to fetch a single disruption by id, no manual poll/refresh trigger, and no direct way to explore inter-line (shared track) correlation despite list_lines exposing that information.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues