Skip to main content
Glama

wsdot-mcp-server

by io.github.cyanheads

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
NameRequiredDescriptionDefault
tripDateNoDate in ISO 8601 format (YYYY-MM-DD). Defaults to today if omitted.
remainingOnlyNoWhen true, returns only future sailings for today. Ignored for future dates. Default: false.
arrivingTerminalIdYesNumeric ID of the arriving terminal.
departingTerminalIdYesNumeric ID of the departing terminal. Use wsdot_get_ferry_terminals to look up terminal IDs.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoOptional notice when no sailings are found — e.g. invalid terminal pair or no service for this date. Absent when sailings are present.
sailingsNoScheduled sailings for this route and date.
tripDateNoDate of the schedule (ISO 8601).
remainingOnlyNoWhether the result shows only remaining sailings.
totalSailingsNoTotal number of sailings returned.
arrivingTerminalNameNoArriving terminal name.
departingTerminalNameNoDeparting terminal name.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "sailings",
+      "tripDate",
+      "remainingOnly",
+      "totalSailings"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
    • addedOutput schema / properties / error
      Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `api_unavailable`: WSF Ferry API is unreachable or returns a non-2xx response after retries. `invalid_access_code`: WSF rejected the request because WSDOT_ACCESS_CODE is missing, invalid, or not registered. `invalid_terminal_pair`: The terminal ID pair is invalid or does not form a valid ferry route. `invalid_date`: The provided tripDate is not a valid ISO 8601 date. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "api_unavailable",
+            "invalid_access_code",
+            "invalid_terminal_pair",
+            "invalid_date"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
    • removedOutput schema / required
      Removed value: -[
-  "sailings",
-  "tripDate",
-  "remainingOnly",
-  "totalSailings"
-]
  2. Changed2 schema fields changed
    • changedOutput schema / properties / sailings / items / properties / arrivalTime / description
      Previous value: -"Scheduled arrival time."New value: +"Scheduled arrival time (ISO 8601, UTC), on the same terms as departureTime. Absent on the routes WSF publishes no arrival time for."
    • changedOutput schema / properties / sailings / items / properties / departureTime / description
      Previous value: -"Scheduled departure time."New value: +"Scheduled departure time (ISO 8601, UTC). WSF publishes schedules in Pacific time, so a sailing late in the service day carries the following UTC calendar date and will not match tripDate. Convert to America/Los_Angeles before showing a clock time."
  3. Changed1 schema field changed
    • removedOutput schema / properties / sailings / items / properties / isCancelled
      Removed value: -{
-  "description": "Whether this sailing is cancelled.",
-  "type": "boolean"
-}
  4. Changed2 schema fields changed
    • addedOutput schema / properties / notice
      Added value: +{
+  "description": "Optional notice when no sailings are found — e.g. invalid terminal pair or no service for this date. Absent when sailings are present.",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "tripDate",
-  "remainingOnly",
-  "sailings",
-  "totalSailings"
-]New value: +[
+  "sailings",
+  "tripDate",
+  "remainingOnly",
+  "totalSailings"
+]
  5. First observed

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 toolsInspect
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.

Resources