Skip to main content
Glama

Cta

by io.github.pipeworx-io

Cta Train Arrivals

cta_train_arrivals
Read-onlyIdempotent

Real-time Chicago CTA 'L' train arrivals at a station — answers "when is the next train Chicago", next Red Line at Belmont, Blue Line to O'Hare from Clark/Lake. Returns each upcoming train's line color, destination, arrival time and minutes_away, plus approaching / delayed / scheduled-only flags and the platform description. Station accepts a name ("Belmont", "Clark/Lake", "O'Hare") or a 5-digit mapid (e.g. 41320). Example: cta_train_arrivals({ station: "Belmont", route: "Red" })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxNoMax arrivals to return, 1-20 (default 8)
routeNoOptional 'L' line filter: Red, Blue, Brown, Green, Orange, Purple, Pink, or Yellow (also disambiguates same-named stations)
_apiKeyNoOptional: your own CTA credentials as "train_key:bus_key" — Train Tracker key (free at transitchicago.com/developers) + Bus Tracker key (free at ctabustracker.com)
stationYesStation name (e.g. "Belmont", "Clark/Lake", "O'Hare", "Midway") or 5-digit mapid (e.g. "41320")

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "_apiKey": "your-cta-api-key",
+    "route": "Red",
+    "station": "Belmont"
+  },
+  {
+    "_apiKey": "your-cta-api-key",
+    "max": 5,
+    "station": "Clark/Lake"
+  }
+]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false. The description adds behavioral context beyond annotations: it specifies the return format (line color, destination, arrival time, minutes_away, flags, platform description) and how station input works (name or mapid). No contradictions with annotations.

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?

The description is a single, well-structured paragraph. It front-loads the main purpose, includes examples, and lists key outputs. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters and no output schema, the description adequately explains return values (train details, flags, platform) and input formats. It covers what the agent needs to know for invocation. Slightly missing details on error handling or timezone but sufficient given complexity.

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 description coverage is 100%. The description adds meaning beyond schema by explaining that station can be a name or mapid, route disambiguates same-named stations, and max limits arrivals. Example usage clarifies parameter interaction.

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 clearly defines the tool's purpose: real-time CTA 'L' train arrivals at a station. It uses specific verbs ('returns', 'answers') and resources ('next train', 'line color'). It distinguishes from siblings like cta_train_positions by focusing on arrivals at a station rather than train positions.

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

Usage Guidelines3/5

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

The description provides clear context with examples and acceptable inputs (station name or mapid), but does not explicitly state when to use this tool versus alternatives like cta_train_positions. No exclusions or when-not scenarios are mentioned.

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

All Cta toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Several tools have heavily overlapping purposes: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, and validate_claim all accept natural-language factual questions, and ask_pipeworx_beta is explicitly described as currently identical to ask_pipeworx. The entity tools (entity_profile, compare_entities, recent_changes, resolve_entity) and the many Polymarket tools also blur together, making misselection likely.

Naming Consistency3/5

Most names are snake_case and readable, with recognizable prefixes like cta_, polymarket_, and ask_pipeworx_. However, conventions are mixed: bare verbs (remember, forget, subscribe), noun-style phrases (entity_profile, bet_research), and variants like ai_visibility_check vs scan_competitor_ai_presence prevent a single predictable pattern.

Tool Count2/5

35 tools is above the comfortable range, and the count is especially mismatched for a server named 'Cta': only 4 tools actually concern Chicago transit, while the other 31 form a general-purpose research, prediction-market, and memory suite. The set feels like multiple unrelated servers merged together.

Completeness2/5

As a CTA server, the surface is notably incomplete: it has bus/train positions and predictions but lacks alerts, service disruptions, route listings, and station/stop metadata. The broader Pipeworx tools are extensive but appear bolted on, so the overall set has no coherent domain against which completeness can be judged.

Resources