F
licenseNot graded
qualityD
maintenanceA versatile Model Context Protocol server that enables AI assistants to manage calendars, track tasks, handle emails, search the web, and control smart home devices.
23
-
Caltrain MCP Server
by davidyen1124
You can query Caltrain schedules and station info through a remote, read-only MCP server.
Get the next scheduled departures between two stations, optionally at a specific local ISO-8601 datetime.
Use common station abbreviations like
sf,sj, and22nd, or list all stations when names are unclear.Handle schedule nuances such as holiday/weekend service, transfers when no direct train exists, and late-night trains belonging to the prior day.
In MCP Apps hosts, README mentions an interactive full-day timetable view via
get_timetablewith Express/Limited/Local filters (not present in the provided schema).
Integrates with GitHub Actions for CI/CD pipelines, automated testing, linting, and publishing releases to PyPI.
Uses pre-commit hooks for code quality checks before committing changes to the repository.
Publishes packages automatically to PyPI using trusted publishing with OIDC authentication, allowing users to install the MCP server directly from the Python package repository.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Caltrain MCP Servernext trains from Palo Alto to San Francisco"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Caltrain MCP
A remote MCP server that tells you exactly when the next Caltrain leaves, so you can be precisely informed about how late it is. It runs on Caltrain's official GTFS schedule, which means the disappointment is official too.
Server: https://caltrain-mcp-rho.vercel.app/mcp (Streamable HTTP, no auth). Live demo at caltrain-mcp-rho.vercel.app.
In ChatGPT and other MCP Apps hosts, answers come with an interactive timetable. Tap a train for its stops, or open the whole day with Express / Limited / Local filters and keep asking questions about what's on screen. Everywhere else you get the same answer as text.
What it knows
The next trains between two stations, or the last ones that still get you there by 9.
That the 12:05 AM train belongs to yesterday, that Thanksgiving runs a weekend schedule, and that South County doesn't do weekends.
Where to change trains when there's no direct one.
That
sf,sjand22ndare stations, because nobody types "San Francisco Caltrain Station".
Tools: next_trains, list_stations, and get_timetable (only the timetable view calls that one). All read-only.
Related MCP server: Google Calendar MCP Server
Development
npm install
npm run dev # http://localhost:3000, MCP at /mcp
npm testIt's Next.js on Vercel:
Schedule engine:
lib/schedule.ts.Timetable view:
widget/, React, Tailwind and shadcn built into one HTML file.Feed:
data/gtfs/. A weekly GitHub Action fetches a fresh one and opens a PR, and merging deploys it.
When the view changes, bump TIMETABLE_URI in lib/mcp/constants.ts. ChatGPT caches it harder than you'd think.
The old Python package on PyPI (uvx caltrain-mcp) still installs, but it's retired. Use the URL above.
License
LICENSE.md. Uses official Caltrain GTFS data; not affiliated with Caltrain. If the train is late, take it up with them.
Available Tools
2 toolslist_stationsA
List all available Caltrain stations.
This tool is useful when you need to find the exact station names, especially if the next_trains() tool returns a "Station not found" error. Station names are case-insensitive and support some common abbreviations like 'SF' and 'SJ'.
Returns a formatted list of all Caltrain stations that can be used as origin or destination in the next_trains() tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It reveals case-insensitive matching and common abbreviations, but does not specify the response format beyond 'formatted list'.
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 three sentences, each earning its place: first sentence states purpose, second adds usage context, third details behavior. No unnecessary words.
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 parameterless tool with no output schema, the description adequately covers input and output behavior. It explains the output is a 'formatted list', which is acceptable, though additional output structure details would improve completeness.
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?
The tool has no parameters, so the description trivially meets requirements. Baseline score of 4 applies; no additional param details needed.
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 precisely states the tool lists all Caltrain stations, explains its utility for resolving errors from next_trains, and distinguishes itself from the sibling tool by focusing on station name discovery.
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 provides a concrete use case: when next_trains returns 'Station not found', making the when-to-use clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
next_trainsA
Return the next few scheduled Caltrain departures.
Args: origin: Station name (e.g. 'San Jose Diridon', 'Palo Alto', 'San Francisco'). Supports common abbreviations like 'SF' for San Francisco, 'SJ' for San Jose. If station is not found, use list_stations() to see all available options. destination: Station name (e.g. 'San Francisco', 'Mountain View', 'Tamien'). Supports common abbreviations like 'SF' for San Francisco, 'SJ' for San Jose. If station is not found, use list_stations() to see all available options. when_iso: Optional ISO-8601 datetime (local time). Default: now.
Note: If you get a "Station not found" error, try using the list_stations() tool first to see exact station names, then retry with the correct spelling.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | ||
| when_iso | No | ||
| destination | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses error handling ('Station not found' leads to list_stations) and notes default time behavior. Could add more on return format or rate limits, but covers key traits.
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?
Description is front-loaded with purpose, then breaks into args with docstring style, and ends with a helpful note. Slightly verbose but efficient for the complexity. Could merge the last sentence into args section.
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?
Given no output schema and 3 parameters, description covers key aspects: purpose, parameters, error handling, and sibling reference. Lacks explicit mention of output structure (e.g., list of departure times), but the phrase 'next few scheduled Caltrain departures' implies a list, which is sufficient.
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 0%, so description must compensate. It fully explains 'origin' and 'destination' with station name examples and abbreviations, and 'when_iso' with ISO-8601 format and default. Adds practical tips for misspellings.
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 states the tool returns 'the next few scheduled Caltrain departures', with specific verb and resource. It distinguishes from sibling 'list_stations' by focusing on departures between two stations.
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 explains when to use this tool (for departures), provides alternative when station not found ('use list_stations()'), and gives examples of acceptable inputs. No ambiguity about usage context.
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.
2 tool updates
v1.0.0- First observed
list_stations - First observed
next_trains
TDQS
A4.4/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one lists all stations, the other retrieves upcoming departures. There is no overlap in functionality.
Naming Consistency4/5
Tool names are readable and follow a descriptive pattern, but 'list_stations' uses verb_noun while 'next_trains' uses adjective_noun, which is a minor inconsistency.
Tool Count3/5
With only 2 tools, it covers the basic station listing and departure lookup, but feels minimal for a transportation server. Additional tools like route or alert info would be expected for completeness.
Completeness4/5
The tool set covers the core workflow of finding stations and getting departures. However, there is no way to get details about a specific train or receive alerts, which are minor gaps.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables natural language interaction with Google Calendar, allowing users to view, create, update, and delete calendar events through context-aware operations.92 npm1MIT
- AlicenseAqualityDmaintenanceA Model Context Protocol server that allows large language models to search for and analyze Chinese railway (12306) tickets through a simple API interface.83,940 npm18MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server for Google Calendar integration, enabling AI assistants to manage events, check availability, and work with multiple accounts and calendars.92 npmMIT