wsdot-mcp-server

Get Ferry Terminals

wsdot_get_ferry_terminals

Read-only

Returns all WSF ferry terminals with their numeric IDs, names, abbreviations, and coordinates. Call this first to resolve human-readable terminal names (e.g. "Bainbridge Island", "Seattle", "Kingston") to the numeric terminal IDs required by the schedule and space tools. The terminal list is small (20 terminals) and rarely changes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Optional notice when no terminal data is available. Absent on normal results.
`terminals`	No	All WSF ferry terminals.
`totalCount`	No	Total number of terminals returned.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 24, 2026

changedOutput schema / properties / terminals / items / properties / terminalId / description

Previous value: -"Numeric terminal ID used in schedule and space API calls."New value: +"Numeric terminal ID used in schedule and space API calls. Absent when upstream omits it."

changedOutput schema / properties / terminals / items / properties / terminalName / description

Previous value: -"Full terminal name (e.g. \"Bainbridge Island\")."New value: +"Full terminal name (e.g. \"Bainbridge Island\"). Absent when upstream omits it."

removedOutput schema / properties / terminals / items / required
```
Removed value: -[
-  "terminalId",
-  "terminalName"
-]
```

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": [
+      "terminals",
+      "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. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "api_unavailable",
+            "invalid_access_code"
+          ],
+          "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: -[
-  "terminals",
-  "totalCount"
-]

Changed2 schema fields changedMay 30, 2026

addedOutput schema / properties / notice

Added value: +{
+  "description": "Optional notice when no terminal data is available. Absent on normal results.",
+  "type": "string"
+}

changedOutput schema / properties / totalCount / description

Previous value: -"Total number of terminals."New value: +"Total number of terminals returned."

First observedMay 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The readOnlyHint annotation already flags this as a safe read operation, and the description adds useful behavioral context beyond that: it returns the complete terminal list with no filtering, includes coordinates, and notes that the list is small and rarely changes. This helps set expectations about result size and data stability.

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 short sentences with no filler. The first sentence states the core behavior and output, the second gives the practical call sequence, and the third adds data size/stability context. Every sentence earns its place.

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 no-parameter, read-only list tool with an output schema, the description is complete. It names the returned fields, explains why an agent should call it, and supplies enough context about the terminal list size that an agent can predict the response shape and cost.

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 zero parameters and the schema already documents this with 100% coverage, so there are no parameter semantics to explain. The description reinforces that it returns all terminals, which is consistent with there being no filtering inputs.

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 uses a specific verb and resource: it returns all WSF ferry terminals, and names the exact fields included. This clearly distinguishes the tool from siblings like ferry routes, schedules, or terminal space tools without needing to open 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?

The description explicitly says to call this first to resolve human-readable terminal names into the numeric IDs required by schedule and space tools. This gives an agent a clear precondition and workflow context for when the tool should be used.

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.