wsdot-mcp-server

Get Ferry Routes

wsdot_get_ferry_routes

Read-only

Returns the main WSF ferry routes operating on a given date, each with the directed terminal pairs it serves that day (terminalPairs) — departing and arriving terminal IDs and names, which are exactly the pairs wsdot_get_ferry_schedule accepts for that date. Route IDs correspond to impactedRouteIds in ferry alerts from wsdot_get_ferry_alerts, though some alert route IDs (seasonal, San Juan interisland, or Sidney B.C.) may not appear in this list. For the full terminal list with coordinates, use wsdot_get_ferry_terminals.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tripDate`	No	Date for which to list routes, in ISO 8601 format (YYYY-MM-DD). Defaults to today if omitted.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Optional notice when no routes are available for the date. Absent on normal results.
`routes`	No	Ferry routes operating on the requested date.
`tripDate`	No	Date for which routes were retrieved (ISO 8601).
`totalCount`	No	Total number of routes returned.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 24, 2026

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"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_date`: The provided tripDate is not a valid ISO 8601 date. Other values are possible when a failure originates below the handler."New value: +"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_date`: The tripDate is not a valid YYYY-MM-DD date, or WSF rejects it as outside the dates it has published a schedule for. Other values are possible when a failure originates below the handler."

addedOutput schema / properties / routes / items / properties / terminalPairs

Added value: +{
+  "description": "Directed terminal pairs this route serves on the requested date; empty when it serves none. Absent only when upstream omits the route ID the lookup needs.",
+  "items": {
+    "additionalProperties": false,
+    "description": "One direction of service between two terminals on the requested date.",
+    "properties": {
+      "arrivingTerminalId": {
+        "description": "Arriving terminal ID — the arrivingTerminalId to pass to wsdot_get_ferry_schedule.",
+        "type": "number"
+      },
+      "arrivingTerminalName": {
+        "description": "Arriving terminal name. Absent when upstream omits it.",
+        "type": "string"
+      },
+      "departingTerminalId": {
+        "description": "Departing terminal ID — the departingTerminalId to pass to wsdot_get_ferry_schedule.",
+        "type": "number"
+      },
+      "departingTerminalName": {
+        "description": "Departing terminal name. Absent when upstream omits it.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "departingTerminalId",
+      "arrivingTerminalId"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed6 schema fields changedAug 25, 2026

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": [
+      "routes",
+      "tripDate",
+      "totalCount"
+    ]
+  },
+  {
+    "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_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_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: -[
-  "routes",
-  "tripDate",
-  "totalCount"
-]

Changed1 schema field changedMay 30, 2026

addedOutput schema / properties / notice

Added value: +{
+  "description": "Optional notice when no routes are available for the date. Absent on normal results.",
+  "type": "string"
+}

First observedMay 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The readOnlyHint annotation already covers the safety profile. The description adds meaningful behavioral context: it clarifies the scope (main routes), explains the correspondence to alert route IDs, and warns about exceptions (seasonal, interisland, Sidney B.C.). This goes beyond the annotation and helps an agent anticipate 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 three sentences, each adding value: the core purpose, the cross-tool relationships, and an explicit alternative. It is front-loaded with the primary function and avoids redundancy, though it could be slightly more compact without losing essential guidance.

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 single-parameter, read-only tool with an output schema, the description covers everything an agent needs: the date handling, the structure of returned terminalPairs, the linkage to schedule and alerts, and the alternative for terminal coordinates. Nothing critical 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?

The sole parameter tripDate is fully documented in the schema (ISO format, default to today). The description does not add parameter-specific details beyond what the schema provides, and schema coverage is 100%, so a baseline of 3 is appropriate.

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: 'Returns the main WSF ferry routes' and specifies the output structure (terminalPairs with IDs and names). It differentiates from siblings by explicitly linking to wsdot_get_ferry_schedule and wsdot_get_ferry_alerts, so an agent can tell this tool apart without opening other 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?

It explicitly names an alternative tool for full terminal lists ('For the full terminal list with coordinates, use wsdot_get_ferry_terminals') and provides a caveat about which alert route IDs may be absent. It also clarifies that the terminalPairs are exactly what wsdot_get_ferry_schedule accepts, giving concrete routing guidance.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.