Skip to main content
Glama

Mbta

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Mbta Departures

mbta_departures
Read-onlyIdempotent

Real-time MBTA train arrival and departure predictions at a Boston station — answers "when is the next train Boston", next Red Line subway at South Station, Green Line trolley, commuter rail departures, Silver Line and bus arrivals. Accepts a station name ("South Station", "Harvard") or a place id ("place-sstat"). Falls back to the published schedule when live predictions are empty (common for commuter rail off-peak). Example: mbta_departures({ stop: "South Station", route: "Red" })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stopYesStation name (e.g. "South Station", "Harvard", "Back Bay") or MBTA place id (e.g. "place-sstat")
limitNoMax departures to return, 1-30 (default 8)
routeNoOptional route id to filter, e.g. "Red", "Green-B", "CR-Providence", "SL1", "66" (see mbta_routes)
_apiKeyNoOptional: free MBTA v3 API key from api-v3.mbta.com for higher rate limits
direction_idNoOptional direction filter: 0 or 1 (meaning per route — see direction_destinations from mbta_routes)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "route": "Red",
+    "stop": "South Station"
+  },
+  {
+    "limit": 5,
+    "stop": "Harvard"
+  }
+]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Adds fallback behavior detail ('falls back to published schedule when live predictions are empty') and hints at API key rate limits, going beyond annotations which already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint.

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?

Single paragraph, first sentence captures core purpose, includes concrete examples. No wasted words; every sentence adds value.

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?

Good for a tool with 5 parameters and no output schema: explains what is returned (predictions), fallback, and typical usage. Slightly lower because it doesn't describe the structure of the prediction results, but it's adequate for an agent.

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 baseline is 3. Description provides examples and context (e.g., 'route' can be from mbta_routes) but doesn't add significant meaning beyond the schema's parameter descriptions.

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?

Description explicitly states it provides 'real-time MBTA train arrival and departure predictions' and gives concrete examples like 'next Red Line subway at South Station'. Clearly distinguishes from sibling tools like mbta_routes and mbta_stops.

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?

States when to use: to get predictions for a station with optional filters. Mentions fallback to schedule. No explicit 'when not to use' or alternatives, but the sibling context and examples imply appropriate use cases.

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

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