What a transit request includes
Your MCP client sends Transit MCP a request body with a tool name and the public transit arguments needed to answer it. Depending on the tool, those inputs can include a city, station name or code, route or line identifier, stop identifier, or a location and search radius. The Worker processes request bodies and public transit arguments only to answer the request.
For the 13 original tools, Transit MCP sends the necessary transit inputs to WMATA for DC requests and MTA for NYC requests through server-to-server requests. It does not forward your IP address or conversation to those transit providers. It returns the resulting public transit information to your client. Do not include secrets or unrelated personal information in transit inputs.
The global tools, which also cover the SF Bay Area, read versioned schedules and feed snapshots that the Worker collects on its own schedule from WMATA, MTA (including MTA Bus Time) and 511 SF Bay. They do not fetch transit providers during your request, so your transit inputs for those tools stay with Transit MCP. SF Bay results keep 511 SF Bay and participating-operator attribution.
No account or credential collection
Transit MCP 6.0 does not require accounts and does not intentionally collect GitHub identity, OAuth grants, access tokens, refresh tokens, client registrations, cookies, or browser storage.
If a client still sends an old bearer credential, the Worker removes the Authorization header before dispatch. Transit MCP does not use it to identify you or grant access.
Metro-owned telemetry is allowlisted
Transit MCP writes allowlisted operational telemetry rather than copying arbitrary request data into its own records. The possible fields are protocol era and version, MCP method and tool name, endpoint alias, upstream name, request duration, response status class, and a recognized category based on what your client software reports about itself. Text fields are restricted to a fixed set of supported values; unknown client software names are classified as unclassified.
The client name identifies software, not a person, and is an unverified self-report. The allowlist has no field for your name, account, IP address, or conversation, and it excludes request bodies, transit input values, raw errors, secrets, and full responses. Session headers and correlation identifiers are not recorded. Invalid and unknown fields are dropped before the record is serialized.
To count usage, Transit MCP also stores one record per legacy connection setup and per tool call in a Cloudflare usage-metrics store: the MCP method, tool name, client software name category, deployment environment, response status class, and request duration. Its index is always empty. Legacy setup events are counted separately from tool calls. These records cannot establish unique users or whether traffic is human. Cloudflare keeps these records for about three months; older records may contain fields collected under the previous telemetry policy, which the aggregate usage report does not retrieve.
Short-lived transit-selection state
When a station or journey endpoint is ambiguous, client-held signed request state can persist for up to five minutes. Legacy state contains public station-selection fields: the tool, city, normalized query, and offered station IDs. Global journey selection contains the tool, a request hash, schedule version, and offered endpoint references. It creates no server-side account or session.
Coordinates, place queries, transit references, and itineraries are processed only to answer your request and are excluded from application telemetry. Personal aliases such as home and work are resolved by your client and are not stored by Transit MCP.
Edge and provider logs
Cloudflare necessarily processes network metadata such as your IP address. Cloudflare platform and invocation logs may exist under the service operator’s Cloudflare configuration. Sampled Worker logs and traces contain only Transit MCP’s allowlisted operational telemetry fields. Their contents and retention depend on Cloudflare and the active configuration; Transit MCP does not promise a retention period it cannot enforce.
WMATA, MTA, and 511 SF Bay may also keep access or service logs when they receive upstream requests. Cloudflare and upstream provider logs and policies are outside Transit MCP’s direct control.
Independent services and clients
Third-party processing is subject to the policies of Cloudflare, GitHub hosting, WMATA, MTA, 511 SF Bay, participating Bay Area operators, and your MCP client’s policies as applicable. Claude, OpenAI, Codex, and other clients are independent services with their own policies; this page describes only the Transit MCP operator’s practices.
What Transit MCP does not do
- Transit MCP does not sell personal information.
- There is no advertising on the service.
- Request data is not used for model training by the Transit MCP operator.
- Transit MCP does not track you across websites or apps.
- These legal pages do not run scripts, set cookies, or use browser storage.
Stop processing, questions, or concerns
You can stop Transit MCP processing by disconnecting the service or ceasing requests. Because the service has no user accounts, there is no account profile to retrieve or delete.
For help, a privacy question, or the current security report route, visit Transit MCP Support.