de en es ja ko ru zh

transit

Name: transit
Author: RyK57

by RyK57

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

transit-mcp-server

MCP-Server für die 511.org SF Bay Open Data Transit-API. Bietet einem LLM Live-Daten zum Nahverkehr in der Bay Area – Verkehrsbetriebe, Linien, Haltestellen, Echtzeit-Abfahrten, Fahrzeugpositionen und Service-Meldungen – für BART, Muni, AC Transit, Caltrain, VTA und alle anderen 511-meldenden Betreiber.

6 Tools, alle schreibgeschützt.

Anforderungen

Node.js 18+
Ein kostenloser 511-API-Token von https://511.org/open-data/token

Related MCP server: mcp-bart

Installation

npm install
npm run build

Konfiguration

{
  "mcpServers": {
    "transit": {
      "command": "node",
      "args": ["/absolute/path/to/transit-mcp-server/dist/index.js"],
      "env": { "TRANSIT_511_API_KEY": "your-token-here" }
    }
  }
}

Variable	Erforderlich	Standard	Zweck
`TRANSIT_511_API_KEY`	ja	—	Token von https://511.org/open-data/token
`TRANSIT_511_BASE_URL`	nein	`https://api.511.org`	API-Host überschreiben
`TRANSIT_511_REQUEST_TIMEOUT_MS`	nein	`30000`	Zeitlimit pro Anfrage
`TRANSPORT`	nein	`stdio`	`stdio` oder `http`
`PORT` / `HOST`	nein	`3000` / `127.0.0.1`	HTTP-Transport-Bind-Adresse
`MCP_PATH_SECRET`	bei Hosting	—	Stellt den Endpunkt unter `/mcp/<secret>` bereit. Erforderlich, wenn `HOST` nicht Loopback ist.
`ALLOWED_ORIGINS`	nein	localhost + claude.ai	Kommagetrennte Zulassungsliste für Origins

Das Kontingent ist die Hauptbeschränkung

511 erlaubt 60 Anfragen pro Stunde pro Schlüssel, geteilt über alle Endpunkte. Das ist niedrig genug, um die Nutzung dieser Tools zu prägen:

Lösen Sie Betreiber- und Haltestellencodes einmal auf und verwenden Sie sie dann wieder. Sie ändern sich nicht.
Bevorzugen Sie transit_list_service_alerts ohne operator_id – ein Aufruf deckt alle Verkehrsbetriebe ab.
Polling von transit_next_departures in einer Schleife vermeiden. Zehn Abfragen während eines Pendelwegs sind ein Sechstel des Stundenbudgets.

transit_list_operators meldet, wie viel Budget noch übrig ist, gelesen aus dem RateLimit-Remaining-Header, den 511 bei jeder Antwort zurückgibt. Das Überschreiten des Kontingents führt zu 429; fordern Sie eine Erhöhung bei transitdata@511.org an.

Bereitstellung (für Claude mobile / claude.ai-Connectors)

Gleiche Form wie jeder gehostete MCP-Server: Generieren Sie ein Pfad-Geheimnis mit openssl rand -hex 32, setzen Sie TRANSIT_511_API_KEY und MCP_PATH_SECRET im Plattform-Dashboard, und die enthaltenen Dockerfile und railway.json funktionieren unverändert auf Railway, Render oder Fly. Der Server weigert sich, ohne Geheimnis auf einer öffentlichen Schnittstelle zu starten. /healthz ist ein nicht authentifizierter Liveness-Healthcheck.

Dann auf claude.ai in einem Browser: Anpassen → Connectors → Benutzerdefinierten Connector hinzufügen, URL https://your-app.up.railway.app/mcp/<secret>.

Tools

Netzwerk — transit_list_operators, transit_list_lines, transit_find_stops

Echtzeit — transit_next_departures, transit_list_vehicles

Meldungen — transit_list_service_alerts

Jedes Tool akzeptiert response_format: "markdown" | "json". Markdown ist die Standardeinstellung und für ein LLM optimiert, das es liest; JSON ist die vollständige strukturierte Nutzlast. structuredContent ist unabhängig vom Format immer gefüllt.

Beispiele

„Wann kommt die nächste N Judah?“ → transit_find_stops mit operator_id="SF", query="judah", um den Haltestellencode zu erhalten, dann transit_next_departures mit diesem Code und line="N".

„Läuft BART normal?“ → transit_list_service_alerts mit operator_id="BA".

„Stimmt etwas nicht auf meinem Arbeitsweg?“ → transit_list_service_alerts ohne Operator – ein Aufruf erfasst alle Verkehrsbetriebe der Bay Area.

„Wo sind die Züge gerade?“ → transit_list_vehicles mit operator_id="BA".

Designhinweise

Von Natur aus schreibgeschützt. 511 veröffentlicht keine Schreib-Endpunkte, und jedes Tool trägt readOnlyHint: true. Ein Test bestätigt das.

Ein operator_id, pro Endpunkt zugeordnet. 511 nennt diesen Parameter operator_id auf seinen statischen Endpunkten und agency auf seinen Echtzeit-Endpunkten, für denselben Wert. Jedes Tool hier akzeptiert operator_id und der Client ordnet es zu. Diese Aufteilung ist 511s Problem, nicht das des Aufrufers.

Die beiden Echtzeit-Endpunkte haben wirklich unterschiedliche Hüllen. StopMonitoring hat keinen Siri-Root-Wrapper; VehicleMonitoring schon. Die veröffentlichte Spezifikation zeigt einen für beide – die Spezifikation ist falsch, und das Parsen der dokumentierten Form würde für Abfahrten überhaupt nichts zurückgeben. Beide werden so geparst, wie die Live-API sie tatsächlich ausgibt, mit einem Test, der jeden festhält.

Ankünfte tragen den Countdown, nicht Abfahrten. ExpectedDepartureTime ist in praktisch jeder echten Zeile null, daher würde ein Countdown darauf basierend eine Haltestelle ohne Service anzeigen. ExpectedArrivalTime ist das zuverlässige Feld.

Ein UTF-8-BOM wird vor dem Parsen entfernt. 511 stellt JSON-Bodies ein U+FEFF voran, was ein naives JSON.parse bei einer völlig gültigen Nutzlast zum Scheitern bringt. Authentifizierungsfehler sind Klartext ohne BOM, daher erfolgt das Entfernen nach der Statusprüfung.

Werte, die wie Zahlen und Booleans aussehen, sind es oft nicht. Koordinaten und Peilungen kommen als JSON-Strings an, VehicleAtStop ist der String "false", und "" wird durchgehend verwendet, wo null gemeint ist. Blindes Umwandeln würde eine fehlende Position in ein gültig aussehendes 0,0 vor der Küste Afrikas verwandeln, daher werden leere Strings als abwesend behandelt, nicht als Null.

Der Epoche-Null-Sentinel ist kein Zeitstempel. Eine Fahrt, die geplant ist, aber keinem Fahrzeug zugewiesen wurde, meldet RecordedAtTime von 1970-01-01T00:00:00Z. Es wird als „noch kein Fahrzeug zugewiesen“ dargestellt, nicht als „vor 56 Jahren aufgezeichnet“.

GTFS-Realtime-Enums werden dekodiert. 511s JSON-Alarmdarstellung gibt "effect": 3 aus, wo die XML-Darstellung SignificantDelays sagt. Sowohl Ursache als auch Wirkung werden wieder in Worte übersetzt.

511-interne Pseudo-Agenturen werden herausgefiltert. 5E, 5F, 5O und 5S sind 511 Emergency, Flap Sign, Operations und Staff – sie erscheinen in der Betreiberliste ohne Servicedaten.

Alles ist Pacific. Zeitstempel kommen als UTC an und werden in America/Los_Angeles dargestellt, sodass die Sommerzeit hier einmal behandelt wird, statt vom Modell zweimal im Jahr. Beachten Sie, dass 511s eigenes TimeZone-Feld für jede Bay-Area-Agentur America/Vancouver meldet – ein bekannter Upstream-Datenfehler, der bewusst ignoriert wird.

Kürzung wird immer angegeben. 511 paginiert nicht; es gibt ganze Sammlungen zurück, und eine große Agentur hat Tausende von Haltestellen. Tools akzeptieren ein clientseitiges limit, und jedes gekürzte Ergebnis gibt an, wie viel zurückgehalten wurde, denn eine stillschweigend verkürzte Liste liest sich wie „das ist alles“.

Einschränkungen

Das Stundenkontingent beträgt 60 Anfragen über alle Endpunkte. Das ist die bindende Einschränkung für jeden Workflow.
Betreibercodes sind leicht falsch zu erraten: VTA ist SC (nicht VT), Capitol Corridor ist AM (nicht CC), Tri Delta ist 3D. transit_list_operators druckt diese Fallen in seiner Ausgabe.
Haltestellencodes gehören zu einem Betreiber und sind zwischen Agenturen nicht austauschbar.
transit_find_stops filtert auf diesem Server, daher spart eine enge Abfrage kein Kontingent – die vollständige Haltestellenliste wird in jedem Fall abgerufen.
Echtzeit-Vorhersagen reichen etwa 90 Minuten voraus, und 511 lässt die letzte reine Ankunftshaltestelle einer Linie aus dem Abfahrtsfeed weg.
tripupdates und vehiclepositions sind nur als Protobuf ohne JSON-Option verfügbar, daher werden sie bewusst nicht bereitgestellt – ihre Unterstützung würde eine Protobuf-Abhängigkeit für Daten bedeuten, die die SIRI-Endpunkte bereits abdecken.

Projektstruktur

src/
├── index.ts               # entry point, transport selection
├── constants.ts           # enums, limits, operator-code traps
├── types.ts               # interfaces for every 511 entity
├── services/
│   └── transit-client.ts  # fetch wrapper, auth, BOM stripping, quota tracking, errors
├── schemas/
│   ├── inputs.ts          # Zod input schemas
│   └── outputs.ts         # structuredContent schemas
├── formatters/
│   ├── response.ts        # limiting, truncation, Pacific-time rendering
│   └── entities.ts        # per-entity markdown rendering
└── tools/
    ├── network.ts         # operators, lines, stops
    ├── departures.ts      # real-time arrivals and vehicles
    └── alerts.ts          # service alerts

Tests

npm run build
npm test            # 42 checks: handshake, BOM, envelopes, quirks, errors (mocked API)
npm run test:http   # 17 checks: config validation, path-secret gating, method handling, origins

Beide Suiten laufen gegen einen lokalen Mock, der absichtlich 511s echte Eigenheiten reproduziert – das BOM, den fehlenden Siri-Wrapper, stringifizierte Booleans und Koordinaten, den Epochen-Sentinel und Klartext-Fehlerbodies – denn genau das sind die Dinge, die ein naiver Client falsch macht.

Available Tools

6 tools

transit_find_stopsFind Transit StopsA

Read-onlyIdempotent

Find an agency's stops by name, and get the stop codes the real-time tools need.

This is the bridge between "Downtown Berkeley" and the code transit_next_departures wants. Pass a query: a large agency has thousands of stops, and 511 returns all of them in one unpaginated response.

Args:

operator_id (string): agency code from transit_list_operators
query (string): substring match on the stop name — strongly recommended
limit (number): maximum stops to return (default: 25)
response_format ('markdown' | 'json'): output format (default: 'markdown')

Returns: { "count": number, "total": number, "truncated": boolean, "stops": [ { "id": string, "Name": string, "Location": { "Latitude": string, "Longitude": string } } ] }

Examples:

"When's the next train from Downtown Berkeley?" -> operator_id='BA', query='downtown berkeley', then pass the id to transit_next_departures
"Find Muni stops on Judah" -> operator_id='SF', query='judah'
Don't use when: you already have the stop code

Error Handling:

Stop codes belong to ONE operator and are not interchangeable between agencies
Filtering happens on this server, so a narrow query does not save quota — the full list is fetched either way
511 allows 60 requests per hour across ALL endpoints

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum results to return (max 200)
`query`	No	Case-insensitive substring match on the stop name. Strongly recommended — a large agency has thousands of stops
`operator_id`	Yes	Operator code from transit_list_operators, e.g. 'BA' for BART, 'SF' for Muni
`response_format`	No	Output format: 'markdown' for human-readable, 'json' for machine-readable	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`stops`	Yes
`total`	Yes
`truncated`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior: server-side filtering (no quota savings), unpaginated response from 511, and the 60-request/hour rate limit. It also clarifies that stop codes are operator-specific—valuable context beyond the 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 longer but well-structured with clear sections (Args, Returns, Examples, Error Handling). Each section contributes distinct value: the main purpose is front-loaded, examples are concise, and error handling is pertinent. No fluff or redundancy.

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?

The description is fully self-contained: it includes the return object structure, examples mapping to actual operator IDs, error-handling notes, rate limits, and the relationship to sibling tools. With an output schema present and annotations covering safety, nothing an agent needs to invoke correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description's Args section largely repeats schema descriptions (e.g., 'operator_id' from transit_list_operators, 'query' substring match and 'strongly recommended'). It adds no new per-parameter semantics; the 'strongly recommended' phrasing already appears in the schema. The unpaginated response note is behavioral, not parameter-specific.

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 identifies the tool's purpose: 'Find an agency's stops by name, and get the stop codes the real-time tools need.' It explicitly ties the tool to transit_next_departures, distinguishing it from other transitive tools. The purpose is specific and actionable.

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?

The description provides explicit usage context: 'This is the bridge between "Downtown Berkeley" and the code transit_next_departures wants.' It also states a clear when-not: 'Don't use when: you already have the stop code.' Examples illustrate typical queries, making the intended conditions unambiguous.

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

transit_list_linesList Transit LinesA

Read-onlyIdempotent

List an agency's routes.

Use this to resolve a line name a user mentions into the id the real-time tools filter on, or to answer "what routes does this agency run".

Args:

operator_id (string): agency code from transit_list_operators
query (string): substring match on the line name or public code
limit (number): maximum lines to return (default: 25)
response_format ('markdown' | 'json'): output format (default: 'markdown')

Returns: { "count": number, "total": number, "truncated": boolean, "lines": [ { "Id": string, "Name": string, "PublicCode": string, "TransportMode": string, "Monitored": boolean } ] }

Examples:

"What BART lines are there?" -> operator_id='BA'
"Is there an N line on Muni?" -> operator_id='SF', query='N'
Don't use when: you want stops on a line (use transit_find_stops)

Error Handling:

A large agency returns many lines; use query to narrow rather than raising limit
511 allows 60 requests per hour across ALL endpoints

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum results to return (max 200)
`query`	No	Case-insensitive substring match on the line name or public code
`operator_id`	Yes	Operator code from transit_list_operators, e.g. 'BA' for BART, 'SF' for Muni
`response_format`	No	Output format: 'markdown' for human-readable, 'json' for machine-readable	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`lines`	Yes
`total`	Yes
`truncated`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

The annotations already declare readOnly, idempotent, and non-destructive hints. The description goes further by disclosing the response shape, the truncation flag, the possibility of many results for large agencies, and the 60-request-per-hour rate limit across all endpoints. This adds behavioral context beyond the annotations and contradicts nothing.

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 well-organized with clear sections (Summary, Args, Returns, Examples, Error Handling). It front-loads the purpose and usage, and every sentence adds value—examples, exclusions, rate limits, and return format. Despite covering many aspects, it remains concise and skimmable.

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?

The tool has 4 parameters, an output schema, and sits among 5 siblings. The description covers all essentials: purpose, parameter examples, return structure, error handling, and even the rate limit. There is nothing an agent needs to know to call this correctly that is missing, and the output schema already documents the return shape.

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?

The schema covers all parameters with detailed descriptions (100% coverage), so the description does not need to duplicate that. It adds a few examples (operator_id='BA', 'SF') and clarifies that query is a case-insensitive substring, but these are minor enhancements. The baseline of 3 is appropriate because the schema already carries the main semantic load.

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 states a specific verb ('List') and resource ('an agency's routes'), and immediately explains its practical use (resolving a line name into an id, answering route questions). It explicitly distinguishes itself from a sibling tool ('Don't use when: you want stops on a line (use transit_find_stops)'), which is a clear differentiation.

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?

It gives explicit 'Use this to...' guidance and an explicit 'Don't use when...' with a named alternative. Examples illustrate common queries, and the error handling section advises when to prefer query narrowing over raising limit. This leaves no ambiguity about when to invoke this tool.

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

transit_list_operatorsList Transit OperatorsA

Read-onlyIdempotent

List Bay Area transit agencies and their operator codes.

Start here. Every other tool needs an operator code, and this is what produces them — BART is 'BA', Muni is 'SF', AC Transit is 'AC', Caltrain is 'CT'.

The Monitored flag matters: agencies reporting real-time data support live departures and vehicle positions, while schedule-only agencies do not.

Args:

monitored_only (boolean): only agencies publishing real-time data (default: false)
limit (number): maximum operators to return (default: 50)
response_format ('markdown' | 'json'): output format (default: 'markdown')

Returns: { "count": number, "total": number, "truncated": boolean, "operators": [ { "Id": string, "Name": string, "Monitored": boolean, "PrimaryMode": string, "TimeZone": string } ] }

Examples:

"What transit agencies are there?" -> call with no arguments
"Which ones have live tracking?" -> monitored_only=true
Call this first whenever the user names an agency, to resolve its code

Error Handling:

Ignore the TimeZone field: 511 reports "America/Vancouver" for every Bay Area agency, which is a known upstream data bug. Everything here is Pacific time
511-internal pseudo-agencies (5E, 5F, 5O, 5S) are filtered out — they carry no service data
511 allows 60 requests per hour across ALL endpoints, so cache this rather than re-fetching

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum results to return (max 200)
`monitored_only`	No	Only agencies that publish real-time data, excluding schedule-only ones
`response_format`	No	Output format: 'markdown' for human-readable, 'json' for machine-readable	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`total`	Yes
`operators`	Yes
`truncated`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond those: the Monitored flag semantics, the known TimeZone bug (inaccurate 'America/Vancouver' values), the filtering of pseudo-agencies (5E, 5F, 5O, 5S), and the rate limit (60 req/hour across all endpoints) with caching advice. This is exactly the kind of operational detail an agent needs and the annotations do not provide.

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 thorough but efficiently organized into clear sections (Args, Returns, Examples, Error Handling). Every sentence adds value: the opening line is the purpose, the 'Start here' directive is front-loaded, examples are concise, and error handling covers real-world quirks. No redundancy or filler—each element earns its place.

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?

For a tool with 3 optional parameters and an output schema, the description covers everything needed to call it correctly: it provides default values, return shape (matching the output schema), examples, and critical edge cases (TimeZone bug, filtering, rate limit). Even though the output schema exists, the description's inclusion of the return shape is redundant but not harmful; the error-handling notes are essential and not available anywhere else. The description is fully sufficient for an agent to use this tool without surprises.

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 100%, so baseline is 3. The description goes beyond the schema by explaining the semantic impact of monitored_only (supports live departures/vehicle positions vs schedule-only), giving concrete usage examples for each parameter, and clarifying the response_format default. It also mentions the default for limit in prose. While the schema already has descriptions, the description adds contextual meaning that helps an agent decide parameter values appropriately.

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 opens with a clear verb-resource pair: "List Bay Area transit agencies and their operator codes." It immediately differentiates from siblings by noting "Every other tool needs an operator code, and this is what produces them," which is unique among the sibling tools. The specific examples (BART='BA', Muni='SF') further cement the purpose.

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?

Explicitly instructs when to use: "Start here." and "Call this first whenever the user names an agency, to resolve its code." It also explains the monitored_only flag's relevance for choosing between live vs schedule-only agencies, effectively guiding the agent on when to apply different parameter values. No alternatives are named, but the tool is clearly positioned as the entry point, so exclusion guidance is unnecessary.

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

transit_list_service_alertsList Transit Service AlertsA

Read-onlyIdempotent

Service alerts — delays, outages, detours and planned disruptions.

Answers "is BART running normally", "why is my line delayed" and "anything I should know before I leave". Omit operator_id to sweep every Bay Area agency in a single request, which is also the kinder option against the hourly quota.

Args:

operator_id (string): limit to one agency; omit for all operators
query (string): substring match on the headline or description
active_only (boolean): only alerts whose active period covers now (default: true)
limit (number): maximum alerts to return (default: 25)
response_format ('markdown' | 'json'): output format (default: 'markdown')

Returns: { "count": number, "total": number, "truncated": boolean, "alerts": [ { "id": string, "header": string, "description": string, "effect": string, "cause": string, "routes": [string], "start": number, "end": number } ] // epoch SECONDS }

Examples:

"Any BART delays?" -> operator_id='BA'
"Anything wrong on my commute?" -> omit operator_id, read across agencies
"Weekend track work?" -> active_only=false, query='weekend'
Don't use when: you want a specific stop's arrivals (use transit_next_departures)

Error Handling:

No alerts is genuinely good news, not an error — it means normal service
Timestamps here are epoch seconds, unlike the ISO strings elsewhere in this API
Setting active_only=false surfaces future planned work as well as current problems
511 allows 60 requests per hour across ALL endpoints

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum results to return (max 200)
`query`	No	Case-insensitive substring match on the alert headline or description
`active_only`	No	Only alerts whose active period covers now
`operator_id`	No	Limit to one agency; omit for alerts across every Bay Area operator
`response_format`	No	Output format: 'markdown' for human-readable, 'json' for machine-readable	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`total`	Yes
`alerts`	Yes
`truncated`	Yes

TDQS

A5/5.0

Behavior5/5

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

Annotations only indicate read-only, idempotent, and non-destructive behavior. The description adds crucial behavioral nuance: no alerts means normal service (not an error), timestamps are epoch seconds unlike the ISO strings in other API endpoints, active_only=false surfaces future planned work, and rate limits. This goes well beyond the 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?

Structured with Args, Returns, Examples, and Error Handling sections. The purpose and primary use cases are front-loaded in the first sentence, and every sentence adds value—examples, rate limits, or format distinctions. No redundancy or fluff.

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?

The output schema is present and the description includes a return format example with field types. It covers error handling (no alerts ≠ error), rate limits, timestamp format, and sibling routing. For a 5-parameter tool with no required parameters, this is fully complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning: operator_id omission sweeps all agencies and is 'kinder' against quota, active_only=false is tied to 'weekend track work' examples, and query is illustrated with a practical use case. These contextual insights help an agent choose parameter values effectively.

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 states a specific verb ('List') and resource ('Transit Service Alerts'), and grounds it with concrete questions it answers ('is BART running normally', 'why is my line delayed'). It explicitly differentiates from the sibling transit_next_departures by naming when not to use it, making the purpose unmistakable.

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?

Explicitly states when to use the tool (answering delay/outage questions) and when not to ('Don't use when: you want a specific stop's arrivals (use transit_next_departures)'). Also gives operational guidance, such as omitting operator_id to sweep all agencies and conserve quota—practical context an agent needs.

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

transit_list_vehiclesList Transit Vehicle PositionsA

Read-onlyIdempotent

Live positions of an agency's vehicles currently in service.

Answers "where are the trains right now" and "how many buses are running on this line". For "when does one get to me", use transit_next_departures instead.

Args:

operator_id (string): agency code from transit_list_operators
line (string): only vehicles on this line, matched on name or id
limit (number): maximum vehicles to return (default: 25)
response_format ('markdown' | 'json'): output format (default: 'markdown')

Returns: { "count": number, "total": number, "truncated": boolean, "vehicles": [ { "line": string, "vehicle": string, "destination": string, "latitude": number | null, "longitude": number | null, "bearing": number | null, "recorded_at": string } ] }

Examples:

"How many Muni trains are running on the N?" -> operator_id='SF', line='N'
"Where are the BART trains?" -> operator_id='BA'
Don't use when: you want arrival times at a stop (use transit_next_departures)

Error Handling:

Coordinates arrive as strings and may be empty; those vehicles report "position unavailable" rather than a false 0,0
An agency with no real-time feed returns nothing — check Monitored in transit_list_operators
511 allows 60 requests per hour across ALL endpoints

ParametersJSON Schema

Name	Required	Description	Default
`line`	No	Only vehicles on this line
`limit`	No	Maximum results to return (max 200)
`operator_id`	Yes	Operator code from transit_list_operators, e.g. 'BA' for BART, 'SF' for Muni
`response_format`	No	Output format: 'markdown' for human-readable, 'json' for machine-readable	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`total`	Yes
`vehicles`	Yes
`truncated`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already signal read-only, idempotent, and open-world behavior. The description adds valuable, non-obvious behavioral details: coordinates arrive as strings and may be empty, agencies with no real-time feed return nothing (with a pointer to check 'Monitored'), and a 60-requests-per-hour rate limit. This goes well beyond the annotations and prepares the agent for realistic edge cases.

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 description is longer than strictly necessary because it repeats the Args and Returns sections that already exist in the schema. However, it is well-structured with clear sections (purpose, args, returns, examples, error handling) and the most important guidance (purpose and alternative) is front-loaded. Every section adds unique value (examples, error handling, rate limits), so the length is justified despite some redundancy.

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?

For a list tool with an output schema and read-only annotations, the description covers all essential context: proper use cases, alternatives, parameter semantics, edge cases (missing coordinates, empty feeds, rate limits), and concrete examples. Nothing an agent needs to call it correctly 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 100%, so the schema fully documents each parameter. The description adds some meaning beyond that: it clarifies that 'line' matches on name or id, and provides concrete examples (operator_id='SF', line='N') that illustrate how parameters map to real queries. Defaults for limit and response_format are repeated, but the examples and matching detail provide modest added value.

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 opens with a clear, specific statement of what the tool does: 'Live positions of an agency's vehicles currently in service.' It names the resource (vehicles) and action (list positions), and explicitly differentiates from a sibling tool ('For "when does one get to me", use transit_next_departures instead'), so an agent can distinguish it without opening schemas.

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?

Provides explicit when-to-use guidance: answers 'where are the trains right now' and 'how many buses are running on this line', and gives a direct exclusion: 'Don't use when: you want arrival times at a stop' with the alternative named. Examples reinforce correct usage and operator/line selection.

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

transit_next_departuresNext Transit DeparturesA

Read-onlyIdempotent

Live arrival predictions for the next vehicles at a stop.

This is the tool for "when is my next train/bus". It returns real-time predictions, not the printed timetable, and reports minutes-from-now alongside Pacific clock time.

Args:

operator_id (string): agency code from transit_list_operators, e.g. 'BA', 'SF'
stop_code (string): stop code from transit_find_stops. Codes belong to ONE operator and are not interchangeable between agencies
line (string): only departures on this line, matched on name or id
limit (number): maximum departures to return (default: 10)
response_format ('markdown' | 'json'): output format (default: 'markdown')

Returns: { "count": number, "total": number, "truncated": boolean, "operator": string, "stop_code": string, "stop_name": string, "retrieved_at": string, "departures": [ { "line": string, "destination": string, "expected": string, "aimed": string, "minutes": number, "vehicle": string | null, "at_stop": boolean } ] }

Examples:

"When's the next N Judah?" -> operator_id='SF', stop_code from transit_find_stops, line='N'
"Next BART from Downtown Berkeley?" -> operator_id='BA', the stop's code
Don't use when: you want the scheduled timetable rather than live predictions

Error Handling:

An empty result usually means service has ended for the night, or the stop is a route's final stop — 511 omits arrival-only terminals from this feed
Predictions extend roughly 90 minutes ahead; nothing beyond that appears
Rows reading "scheduled only, no live prediction" have no vehicle assigned yet
511 allows 60 requests per hour across ALL endpoints — never poll this in a loop

ParametersJSON Schema

Name	Required	Description	Default
`line`	No	Only departures on this line, matched against the line name or id
`limit`	No	Maximum results to return (max 200)
`stop_code`	Yes	Stop code from transit_find_stops. Codes are specific to one operator
`operator_id`	Yes	Operator code from transit_list_operators, e.g. 'BA' for BART, 'SF' for Muni
`response_format`	No	Output format: 'markdown' for human-readable, 'json' for machine-readable	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`total`	Yes
`operator`	No
`stop_code`	No
`stop_name`	No
`truncated`	Yes
`departures`	Yes
`retrieved_at`	No

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds substantial behavioral context: real-time vs static, minutes-from-now plus Pacific clock time, 'scheduled only' rows, a 90-minute prediction horizon, empty results meaning (end of service or arrival-only terminal), and a 60-requests-per-hour rate limit. This goes far beyond the annotations, providing critical operational details an agent needs to interpret results and avoid misuse.

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?

Structured with clear sections (Purpose, Args, Returns, Examples, Error Handling) and front-loaded with the core purpose. Every sentence adds value; error handling is critical for correct agent behavior. It is detailed but not flabby — the length is justified by the operational caveats and edge cases.

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?

For a tool with 5 parameters and an output schema, the description covers all essential usage aspects: parameter semantics, error scenarios (empty results, truncated predictions), time horizon, rate limits, and a full output structure in the Returns section. Even though an output schema is provided, the description's explicit sample JSON and explanation of fields further aid the agent. Nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description enriches every parameter: it provides real examples (operator_id 'BA'/'SF', stop_code from transit_find_stops), warns that stop codes are operator-specific and not interchangeable, clarifies line matching ('matched on name or id'), and explains response_format options. The Args section adds value beyond the schema's terse descriptions, especially for stop_code and line.

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 states a specific verb and resource: 'Live arrival predictions for the next vehicles at a stop' and explicitly positions it as 'the tool for when is my next train/bus'. It distinguishes from the printed timetable and clarifies scope (real-time, not static), making it clearly different from sibling tools that list operators, stops, lines, vehicles, or alerts.

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?

Provides explicit when-to-use guidance via examples ('When's the next N Judah?' maps to specific parameters), an explicit 'Don't use when' exclusion for scheduled timetable, and references prerequisite tools (transit_list_operators, transit_find_stops) for parameter sourcing. It also includes rate-limit guidance ('never poll this in a loop'), which is directly relevant to usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0Aug 25, 2026
- First observedtransit_find_stops
- First observedtransit_list_lines
- First observedtransit_list_operators
- First observedtransit_list_service_alerts
- First observedtransit_list_vehicles
- First observedtransit_next_departures

Deploy Server

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

TDQS

A4.8/5.0

Scored 2026-08-25 04:40 across 6 tools

Disambiguation5/5

Each tool targets a distinct resource: operators, lines, stops, departures, vehicles, and alerts. Descriptions explicitly cross-reference when to use which (e.g., 'Don't use when' sections), eliminating ambiguity. No two tools overlap in purpose.

Naming Consistency5/5

All tools share the 'transit_' prefix and follow a consistent verb-object pattern: list_operators, list_lines, find_stops, next_departures, list_vehicles, list_service_alerts. Minor variation between 'list', 'find', and 'next' but the style is uniform and predictable.

Tool Count5/5

Six tools are well-scoped for a transit information server, covering discovery (operators, lines, stops), real-time queries (departures, vehicles), and alerts. No tool is redundant, and the count feels neither sparse nor bloated.

Completeness4/5

The tool surface covers the full workflow of querying transit info: discover agencies, lines, stops, then get live departures, vehicle positions, and alerts. A minor gap is the lack of a dedicated scheduled timetable tool, though the departures endpoint includes aimed times. Overall, the domain is well covered.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Live Times Transit
io.github.travelwhiz-ltd
Read-only public transit departures, stop search, and city coverage for bus and train users.
Travel & Transportation Location Services
1
BART Real-Time Transit A
io.github.srivastsh
Real-time BART departures, trip planning, fares, stations, and advisories.
Travel & Transportation Location Services
721
onebusaway-mcp-server A
io.github.cyanheads
Real-time transit stops, routes, arrivals, vehicle positions, and schedules via OneBusAway APIs.
Travel & Transportation Location Services
1621
SF Muni Real-Time Transit A
io.github.srivastsh
Real-time SF Muni departures, routes, alerts, vehicle positions, and schedules.
Travel & Transportation Location Services Search
21

Related MCP Servers

MBTA MCP Server
Travel & Transportation Location Services
cubismod
A
license
B
quality
F
maintenance
Enables AI clients to access Boston's MBTA public transit data, including real-time predictions, schedules, route planning, and service alerts.
Updated 7 months ago (2026-03-16 07:51 UTC)
32
1
Apache 2.0
mcp-bart
Travel & Transportation Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Provides real-time San Francisco Bay Area Rapid Transit data, enabling queries about BART schedules, routes, and station information through natural language.
Updated 20 days ago (2026-09-25 22:04 UTC)
24 npm
MIT
mcp-transit-land
Travel & Transportation Location Services
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables querying global transit data including agencies, routes, stops, and departures through a GTFS aggregator.
Updated 19 days ago (2026-09-26 22:00 UTC)
22 npm
MIT
Bay Area Transit MCP
Travel & Transportation Location Services
srivastsh
A
license
Not graded
quality
D
maintenance
Enables querying real-time BART and SF Muni transit data, including departures, trip planning, fares, advisories, routes, alerts, vehicle positions, and schedules, from any MCP-compatible client.
Updated 4 months ago (2026-06-01 20:37 UTC)
1
MIT