wsdot-mcp-server

Get Ferry Schedule

wsdot_get_ferry_schedule

Read-only

Returns departure times for a specific WSF ferry route on a given date. Requires numeric terminal IDs — use wsdot_get_ferry_terminals to resolve terminal names to IDs. Set remainingOnly to true to show only future departures for today (useful for "next ferry" queries). For future dates, all sailings for that day are returned. Sailing times are ISO 8601 UTC while tripDate is the Pacific service day, so evening sailings carry the next UTC date — convert to America/Los_Angeles before quoting a clock time. Cancellations are not carried here — WSF drops a cancelled sailing from the schedule instead of flagging it, so a listed sailing is not confirmation that it will run. Check wsdot_get_ferry_alerts for disruptions; those are scoped to a route, not an individual sailing.

Input Schema

TableJSON Schema

Name	Required	Description
`tripDate`	No	Date in ISO 8601 format (YYYY-MM-DD). Defaults to today if omitted.
`remainingOnly`	No	When true, returns only future sailings for today. Ignored for future dates. Default: false.
`arrivingTerminalId`	Yes	Numeric ID of the arriving terminal.
`departingTerminalId`	Yes	Numeric ID of the departing terminal. Use wsdot_get_ferry_terminals to look up terminal IDs.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Optional notice when no sailings are found — e.g. invalid terminal pair or no service for this date. Absent when sailings are present.
`sailings`	No	Scheduled sailings for this route and date.
`tripDate`	No	Date of the schedule (ISO 8601).
`remainingOnly`	No	Whether the result shows only remaining sailings.
`totalSailings`	No	Total number of sailings returned.
`arrivingTerminalName`	No	Arriving terminal name.
`departingTerminalName`	No	Departing terminal name.

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses crucial behaviors: the timezone mismatch (UTC vs Pacific service day), the fact that cancellations are dropped rather than flagged, and the need to check alerts separately. This adds significant context not captured by 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 efficiently structured: starts with the core function, then usage requirements, then behavioral caveats, and ends with guidance on related tools. Every sentence earns its place; no redundant filler.

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?

Given the presence of an output schema and the moderate complexity, the description covers prerequisites, timezone pitfalls, cancellation semantics, and cross-tool references. It fully equips an agent to call the tool correctly without gaps.

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 input schema already has 100% coverage for all four parameters. The description adds extra meaning for tripDate (Pacific service day and timezone note) and reinforces the terminal ID lookup, providing subtle value beyond the schema without repeating verbatim details.

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 begins with a clear specific action: 'Returns departure times for a specific WSF ferry route on a given date.' It distinctly separates from siblings by referencing wsdot_get_ferry_terminals for ID resolution and wsdot_get_ferry_alerts for disruptions, making the tool's scope unambiguous.

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 usage instructions: requires numeric terminal IDs, directs to wsdot_get_ferry_terminals for resolution, explains the remainingOnly behavior for today's future sailings, and advises checking alerts for disruptions. It effectively tells when to use this tool versus alternatives.

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

All wsdot-mcp-server tools Inspect

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

A4.5/5.0

Disambiguation5/5

Every tool targets a distinct resource and action: border waits, ferry routes/schedules/alerts/terminals/space/vessel positions, mountain passes, toll rates, travel times, highway alerts, and cameras. No two tools overlap in purpose; even the two alert tools (ferry vs highway) are clearly separated by domain.

Naming Consistency5/5

All tools follow the wsdot_verb_noun pattern with snake_case. Most use 'get' (get_ferry_routes, get_border_waits, get_mountain_passes) and two use 'search' (search_alerts, search_cameras), which is appropriate for filtering operations. The single deviation (get_terminal_space instead of get_ferry_terminal_space) is minor and does not harm predictability.

Tool Count5/5

12 tools cover a broad but well-scoped domain of WSDOT transportation data. The ferry subsystem alone has 6 focused tools (routes, schedule, alerts, terminals, space, vessel locations), and other areas each have a dedicated tool. The count feels neither inflated nor sparse for the server's purpose.

Completeness5/5

The tool surface covers the full lifecycle of WSDOT information needs: real-time border waits, ferry operations (routes, schedule, alerts, terminal IDs, space, vessel tracking), road conditions (mountain passes, travel times, toll rates), safety alerts, and camera feeds. No obvious dead ends—every query type has a corresponding tool.

Get Ferry Schedule

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources