wsdot-mcp-server

Name: wsdot-mcp-server
Author: cyanheads

Server Details

WA highway conditions, ferry schedules, vessel locations, toll rates, and border waits via MCP.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 38 days
Last Tested: 2026-09-24 01:50
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: cyanheads/wsdot-mcp-server
GitHub Stars: 1
Server Listing: wsdot-mcp-server

TDQS

A4.5/5.0

Scored 2026-09-20 20:30 across 12 tools

Disambiguation5/5

Each tool targets a clearly distinct resource: ferry alerts, ferry routes, schedules, terminals, terminal space, vessel locations, highway alerts, cameras, travel times, toll rates, mountain passes, and border waits. The only potential overlap is ferry alerts vs. highway alerts, but the names and descriptions clearly separate transport modes.

Naming Consistency5/5

All tools follow a consistent wsdot_ prefix with either get_ (for direct resource retrieval) or search_ (for filtered queries). The pattern is uniform and predictable, making it easy for an agent to infer tool naming conventions.

Tool Count5/5

Twelve tools is well-scoped for a transportation data server covering both ferry and highway domains. Each tool covers a distinct data need without unnecessary bloat.

Completeness4/5

The ferry domain is well covered with alerts, routes, schedules, terminals, space, and vessel locations. The highway domain includes alerts, cameras, travel times, toll rates, mountain passes, and border waits, but lacks features like fare info or road surface reports; minor gaps remain but core workflows are covered.

Available Tools

12 tools

wsdot_get_border_waitsGet Border Wait TimesA

Read-only

Inspect

Returns current vehicle wait times at WA→Canada land border crossings: I-5 (Peace Arch, Blaine), SR 543 (Pacific Highway, Blaine), SR 539 (Lynden), and SR 9 (Sumas). Each crossing reports a general-purpose lane and a Nexus lane; SR 539 adds a truck lane and SR 543 adds truck and FAST truck lanes — eleven entries in crossings[], one per lane. crossingName is a route code (e.g. "I5", "I5Nexus", "SR543Trucks"); the readable name is in location.description. Wait times are in minutes. A crossing reporting no current data is still returned — only waitTimeInMinutes is omitted. Use for "how long is the border wait?" questions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Optional notice when no crossing data is available. Absent on normal results.
`crossings`	No	All WA/Canada border crossing wait times.
`totalCount`	No	Total number of crossings returned.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true. The description goes well beyond that: it explains the exact number of entries (eleven), the naming conventions (crossingName as route code, readable name in location.description), the lane structure for each crossing, and the behavior when no data is available (waitTimeInMinutes omitted). This provides rich behavioral context that an agent needs to interpret results correctly.

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 clear and efficient. It front-loads the core purpose, then provides specific structural details (lane counts, naming scheme, data omission behavior) without redundancy. Each sentence adds new information, and the structure flows logically from overview to specifics.

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 tool has no parameters, is read-only, and has an output schema, the description covers everything needed: the specific crossings, lane variations, naming conventions, and missing-data behavior. Even though the output schema exists, the description explains the semantics of the fields, making the tool self-contained and easy to invoke without external context.

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, so the description correctly avoids mentioning any. The baseline for 0 params is 4, and the description doesn't need to add parameter semantics. It does provide context about the output structure, which is more relevant than parameter details here.

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 ('Returns current vehicle wait times') and a clear resource ('WA→Canada land border crossings'). It lists the exact border crossings and lane types, distinguishing it from sibling tools like ferry alerts, mountain passes, or toll rates. The scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final sentence explicitly states when to use the tool: 'Use for "how long is the border wait?" questions.' It also clarifies that crossings without current data are still returned, which sets expectations. It doesn't explicitly say when not to use it, but the sibling tools are clearly distinct domains (ferries, passes, tolls), so exclusions are implicitly obvious.

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

wsdot_get_ferry_alertsGet Ferry AlertsA

Read-only

Inspect

Returns active WSF ferry service disruptions, delays, and bulletins. Each alert carries a one-line summary plus the bulletin title, kind, and full body — the body is where detail such as a replacement sailing appears. Each alert includes impacted route IDs — cross-reference with wsdot_get_ferry_routes to resolve route IDs to human-readable route names. Some IDs (seasonal, San Juan interisland, or international Sidney B.C. routes) may not appear in wsdot_get_ferry_routes for a given date.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`alerts`	No	Active ferry service alerts and disruptions.
`notice`	No	Optional notice when no alerts are active. Absent when alerts are present.
`totalCount`	No	Total number of active alerts.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint: true, so the description correctly avoids repeating that. It adds meaningful behavioral context by explaining the structure of each alert, the presence of route IDs, and the caveat about missing routes. This is more than the annotation provides and helps the agent interpret results. No contradiction with 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 concise and well-structured. It front-loads the core purpose, then gives a brief overview of content, and finally provides cross-referencing guidance. Every sentence adds value without redundancy. It is appropriately sized for the tool's simplicity.

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 tool has no parameters and an output schema (though not shown), the description fully explains what the agent can expect: each alert's structure and how to resolve route IDs. The caveat about missing routes is a useful edge case. All necessary information for calling and interpreting results is present.

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, so the schema is trivially complete. The description doesn't need to explain parameters. Baseline is 4, and the description adds no irrelevant parameter information, so a 4 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 clearly states it returns active WSF ferry service disruptions, delays, and bulletins. It specifies the verb 'Returns', the resource 'WSF ferry service disruptions', and includes details about the alert content (summary, title, kind, body). This distinguishes it from siblings like wsdot_get_ferry_routes and wsdot_get_ferry_schedule.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when to use this tool (for alerts/disruptions) and provides an important cross-referencing instruction with wsdot_get_ferry_routes. It also notes a caveat about route IDs not appearing. While it doesn't explicitly state when NOT to use it, it implies that this is the go-to for disruptions. The guidance is sufficient for an agent to select it appropriately.

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

wsdot_get_ferry_routesGet Ferry RoutesA

Read-only

Inspect

Returns the main WSF ferry routes operating on a given 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. To get terminal IDs for schedule and space lookups, use wsdot_get_ferry_terminals.

ParametersJSON 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

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

TDQS

A4.5/5.0

Behavior4/5

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

The readOnlyHint annotation already flags this as a read operation, so the description doesn't need to repeat that. It adds meaningful context by explaining the relationship between route IDs and alert route IDs, including the caveat about excluded alerts. This goes beyond the structured annotation and helps the agent interpret results correctly, though it omits details like refresh timing or sort order.

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?

Three sentences, each earning its place: the first states the core function, the second explains the correspondence and exceptions, and the third points to the alternative. The main purpose is front-loaded, and there is no redundant or filler content.

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 tool's simplicity (one optional parameter, read-only, output schema provided), the description is complete. It covers the tool's purpose, its relationship to alerts, and the alternative for terminals. No missing information would prevent an agent from calling it correctly.

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 schema describes the tripDate parameter completely (ISO 8601 format, optional, defaults to today), achieving 100% coverage. The description does not add further parameter-specific detail, which is acceptable given the schema already handles it. The baseline of 3 applies because the schema carries the full parameter meaning.

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 main WSF ferry routes operating on a given date.' This specifies the verb, resource, and temporal scope. It also distinguishes itself from siblings by explicitly mentioning the correspondence to impactedRouteIds in ferry alerts and naming the alternative for terminal IDs, so an agent can differentiate it without opening 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 provides explicit guidance: it tells when to use this tool (to get routes for a date) and when it may be insufficient (some alert route IDs like seasonal, San Juan interisland, or Sidney B.C. may not appear). It also directs the agent to wsdot_get_ferry_terminals for terminal IDs, leaving no ambiguity about the appropriate tool choice.

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

wsdot_get_ferry_scheduleGet Ferry ScheduleA

Read-only

Inspect

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.

ParametersJSON 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

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

wsdot_get_ferry_terminalsGet Ferry TerminalsA

Read-only

Inspect

Returns all WSF ferry terminals with their numeric IDs, names, and abbreviations. 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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

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

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description adds value with the stability and size notes (small, rarely changes), which are useful behavioral traits beyond the safety flag. No contradiction.

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?

Three sentences, each earning its place: what it returns, why to call it first, and a note on data stability/size. Front-loaded and perfectly sized without fluff.

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 simple list endpoint with an output schema, the description covers purpose, usage, and data characteristics completely. An agent has everything needed to invoke it correctly.

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, so the description appropriately ignores parameter details. Baseline of 4 is correct; nothing needed to be added.

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?

States exactly what it returns — all WSF ferry terminals with numeric IDs, names, and abbreviations — and explicitly links it to resolving names for schedule and space tools, distinguishing it from siblings like schedules and alerts.

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?

Gives explicit direction to 'Call this first' and explains the use case (resolving human-readable names to numeric IDs needed by other tools). Also notes the list is small and rarely changes, signaling it's a stable lookup.

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

wsdot_get_mountain_passesGet Mountain Pass ConditionsA

Read-only

Inspect

Returns current road conditions for all Washington State mountain passes: status, weather, road condition, traction laws, temperature, and elevation. Includes all 16 passes (Snoqualmie, Stevens, White, Blewett, Cayuse, etc.). Use for "is the pass open?", traction law status, or winter driving planning.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Optional notice when no pass data is available — e.g. API temporarily unavailable. Absent on normal results.
`passes`	No	All WA mountain pass conditions.
`totalCount`	No	Total number of passes returned.

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds context about the data returned (status, weather, etc.) and the full scope of 16 passes, which is useful behavioral context beyond the annotation. However, there is no disclosure of rate limits, authentication needs, or any side effects, and the description does not go beyond what the annotation plus its own purpose statement already communicate.

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 with no waste. The first sentence states purpose and data fields, the second lists the passes, and the third gives usage examples. It is front-loaded with the core function and efficiently structured.

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?

With zero parameters, a read-only hint, and an output schema present, the description covers everything an agent needs to call this tool: what it returns, the full scope of passes, and typical use cases. There is no missing information for correct invocation.

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 accepts zero parameters, and the schema coverage is 100% (there is nothing to document). The description properly indicates the tool needs no input and focuses on the output scope. Per the rubric, a 0-parameter tool receives a baseline of 4, and the description does not need to add parameter 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 states a specific verb ('Returns') and a precise resource ('current road conditions for all Washington State mountain passes'), and lists the data fields it provides (status, weather, road condition, traction laws, temperature, elevation). It also mentions all 16 passes by name, clearly distinguishing this tool from siblings that handle ferries, borders, and cameras.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases: 'Use for "is the pass open?", traction law status, or winter driving planning.' This provides clear context for when to call the tool. However, it does not explicitly mention alternatives or when not to use it, though the sibling differentiation is implicit given the highly specific scope.

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

wsdot_get_terminal_spaceGet Terminal SpaceA

Read-only

Inspect

Returns real-time drive-up and reservable vehicle space available at WSF terminals for upcoming sailings. Use for "will I make the ferry?" or "how full is the next sailing?" questions. Optionally filter to a specific terminal by ID (use wsdot_get_ferry_terminals for the ID). driveUpSpaceCount is the key field — zero means the drive-up lane is full. Destinations are arrivingTerminalIds, not the itineraryLabel string: a sailing can serve several terminals, and those IDs are what wsdot_get_ferry_schedule accepts. Results are paged by terminal (default 5, max 20): offset/limit select whole terminals and totalCount counts matching terminals, not sailings — every sailing of a returned terminal is included, so page size varies with how many departures each terminal carries.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum terminals to return in this page (1–20). Defaults to 5. Counts terminals, not sailings.
`offset`	No	Zero-based index of the first terminal to return, for paging. Defaults to 0.
`departingTerminalId`	No	Filter to a specific terminal by numeric ID. Omit to return all terminals.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Informational note about the page window, or guidance when no terminal space data is available, the filter matched nothing, or the offset ran past the end.
`hasMore`	No	True when more terminals remain beyond the current page.
`terminals`	No	Terminal space availability by terminal.
`nextOffset`	No	Offset to pass to retrieve the next page, or null when this is the last page.
`totalCount`	No	Total terminals matching the filter across all pages (not just this page). Counts terminals, not sailings.
`terminalFilter`	No	The terminal ID filter applied, or absent if no filter was used.

TDQS

A5/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the burden of behavioral detail. It explains the key field driveUpSpaceCount and its meaning (zero = full), and thoroughly discloses pagination behavior: results paged by terminal, offset/limit select whole terminals, totalCount counts terminals not sailings, and page size varies with departures per terminal. This goes well beyond the annotation.

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?

Though multi-sentence, every sentence earns its place: core purpose and use case front-loaded, followed by filtering guidance, destination disambiguation, and pagination semantics. Dense with information, no 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 output schema exists, the description need not list return fields, but it still highlights the crucial driveUpSpaceCount. It covers terminal ID sourcing, destination semantics, and pagination quirks—everything an agent needs to call it correctly for the intended queries.

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 description coverage is 100%, but the description adds substantial value: it tells the agent to obtain departingTerminalId from wsdot_get_ferry_terminals and clarifies the pagination parameters (limit/offset count terminals, not sailings) with the totalCount nuance. This enriches the schema's already-documented parameters.

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?

States a specific verb ('Returns'), resource ('real-time drive-up and reservable vehicle space at WSF terminals for upcoming sailings'), and gives concrete use cases ('will I make the ferry?' or 'how full is the next sailing?'). Clearly distinct from sibling tools like wsdot_get_ferry_schedule (schedule) and wsdot_get_ferry_terminals (terminal list).

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 names the target questions and directs to wsdot_get_ferry_terminals for terminal IDs. Disambiguates arrivingTerminalIds vs itineraryLabel and notes that those IDs are what wsdot_get_ferry_schedule accepts. Provides clear when-to-use and routing to the correct sibling.

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

wsdot_get_toll_ratesGet Toll RatesA

Read-only

Inspect

Returns current dynamic toll rates for WA express lanes and tolled facilities: SR 99 (WSDOT Tunnel), SR 167 HOT Lanes, I-405 Express Lanes, SR 509 tolled segment, and the SR 520 Bridge. Rates are time-banded and change dynamically based on traffic conditions. stateRoute is a bare, zero-padded route number ("099", "405") — the posted designation is in the rendered text. Results are paged — pass offset/limit to page through the full set (the notice reports the next offset).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum toll rates to return in this page (1–500). Defaults to 50.
`offset`	No	Zero-based index of the first toll rate to return, for paging. Defaults to 0.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`rates`	No	Current toll rates for all active tolled facilities.
`notice`	No	Informational note about the page window, or guidance when no toll rate data is available or the offset ran past the end.
`hasMore`	No	True when more toll rates remain beyond the current page.
`nextOffset`	No	Offset to pass to retrieve the next page, or null when this is the last page.
`totalCount`	No	Total toll rate entries across all pages (not just this page).

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: rates are time-banded and dynamic (volatility), results are paged and require offset/limit iteration with the next offset reported in the notice (pagination mechanics), and stateRoute is zero-padded with the posted designation only in rendered text (a data-format gotcha). This substantially exceeds what the annotation alone provides.

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?

Four sentences, zero filler, and the core purpose is front-loaded. The facility enumeration, dynamic-rate caveat, stateRoute gotcha, and pagination note each earn their place as distinct pieces of information an agent needs.

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?

With an output schema present, an annotation covering the safety profile, and fully documented parameters, the description covers the remaining ground: what data is included, how it behaves, how to page through it, and a formatting trap. Nothing an agent needs to invoke this correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3 — both limit and offset are fully documented with ranges and defaults. The description adds genuine extra value by explaining the pagination workflow: pass offset/limit to traverse the full set and rely on the notice for the next offset. This connects the two parameters into an iteration pattern the schema alone does not convey.

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 specific verb and resource — 'Returns current dynamic toll rates' — and enumerates every covered facility (SR 99, SR 167, I-405, SR 509, SR 520 Bridge). This unambiguously distinguishes it from siblings like wsdot_get_mountain_passes or wsdot_get_ferry_schedule, whose names concern entirely different data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear usage context is established: this is the tool for current, dynamic toll rates on WA express lanes and tolled facilities, with the 'time-banded and change dynamically' phrasing signaling real-time data. However, it never explicitly names alternatives or states when not to use it — the distinction from siblings is left to inference from their names.

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

wsdot_get_travel_timesGet Travel TimesA

Read-only

Inspect

Returns current vs. average travel times for named WA highway corridors (I-5, I-90, SR 520, SR 99, I-405, SR 167, etc.). Use for "how congested is I-5?" or commute time estimates. The route filter matches two ways: a route designation ("I-5", "5", "SR 520") returns every corridor measured on that route, and any text also matches corridor names ("Everett"). When current time exceeds average, the corridor is congested. Results are paged — pass offset/limit to page through the full set (the notice reports the next offset).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum corridors to return in this page (1–500). Defaults to 50.
`route`	No	Optional filter. A route designation — "I-5", "5", "005", "SR 520", "520" — matches every corridor whose start or end point is on that route, whichever form the feed reports. Any text also matches the corridor name as a case-insensitive substring, so "Everett" finds the Seattle-Everett corridors. Omit to return all corridors.
`offset`	No	Zero-based index of the first corridor to return, for paging. Defaults to 0.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Informational note about the page window, or guidance when no corridors matched the route filter or the offset ran past the end.
`hasMore`	No	True when more corridors remain beyond the current page.
`corridors`	No	Travel time corridors matching the filter.
`nextOffset`	No	Offset to pass to retrieve the next page, or null when this is the last page.
`totalCount`	No	Total corridors matching the filter across all pages (not just this page).
`routeFilter`	No	The route name filter applied (lowercased), or absent if no filter was used.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds value by explaining current vs. average comparison, congestion inference, and paging behavior (including the notice about next offset). No contradiction with annotations. It could mention that results are not sorted or that multiple corridors per route are returned, but these are minor given the detail present.

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?

Four sentences, front-loaded with purpose and key behaviors. Each sentence carries unique information: return type, use case, filter behavior, congestion logic, and paging. No redundancy or 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 3 optional parameters, 100% schema coverage, an output schema, and readOnlyHint annotation, the description covers all essentials: what it returns, how to filter, how to page, and how to interpret congestion. Nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100% with rich parameter descriptions. The description adds semantic nuance beyond the schema by explaining the dual matching behavior of the route parameter (route designation vs. corridor name substring) and the paging semantics with offset/limit. This goes beyond what the schema alone conveys.

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?

Description starts with a specific verb+resource: 'Returns current vs. average travel times for named WA highway corridors' and lists examples. It clearly distinguishes from ferry, border, and toll tools by domain. An agent can immediately tell this is the highway congestion tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use cases: 'Use for "how congested is I-5?" or commute time estimates.' While it doesn't name alternatives, all sibling tools are in different domains (ferries, borders, tolls), so the context makes it obvious. It also explains the route filter's two matching modes, which is practical usage guidance.

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

wsdot_get_vessel_locationsGet Vessel LocationsA

Read-only

Inspect

Returns real-time AIS positions, speed, heading, ETA, and dock status for all active WSF vessels. Use for "where is the ferry now?", vessel tracking, or checking if a vessel is in service. Position data may lag by 30–60 seconds. Many fields are null for vessels not currently operating.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Optional notice when no vessel data is available. Absent on normal results.
`vessels`	No	All WSF vessels with real-time position data.
`totalCount`	No	Total number of vessels returned.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable behavioral context: position data may lag by 30–60 seconds and many fields are null for non-operating vessels, which helps manage expectations about data freshness and completeness.

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?

Two sentences efficiently pack the return payload, usage guidance, and data caveats. The main functionality is front-loaded, and 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?

With an output schema and readOnlyHint annotation, the description covers all essential aspects: what is returned, when to use it, and important caveats about data lag and nulls. No parameters means nothing else needs explaining.

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 0 parameters, so per the rubric the baseline is 4. The description doesn't need to explain parameters, and no additional parameter-related value is required.

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 states a specific verb ('Returns') and resource ('real-time AIS positions, speed, heading, ETA, and dock status for all active WSF vessels'), clearly distinguishing it from sibling tools like ferry schedules or border waits. It also provides concrete use cases ('where is the ferry now?').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use for' and lists three clear usage scenarios. It does not mention when not to use or alternatives, but since no sibling tool covers vessel location, this is sufficient context without exclusions.

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

wsdot_search_alertsSearch Highway AlertsA

Read-only

Inspect

Returns active WA highway alerts: incidents, construction, closures, and restrictions. Filter by state route ("I-90", "90", "SR 520", or "520" all work), WSDOT region (Northwest, Olympic, Southwest, South Central, North Central, Eastern), or milepost range, matched against the alert's full extent. Omit all filters to return all current statewide alerts. Results are ordered by alertId and paged — pass offset/limit to page through the full set (the notice reports the next offset).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum alerts to return in this page (1–500). Defaults to 50.
`offset`	No	Zero-based index of the first alert to return, for paging. Defaults to 0.
`region`	No	WSDOT region name as it appears in alert data: "Northwest", "Olympic", "Southwest", "South Central", "North Central", or "Eastern". Matching is case-insensitive.
`stateRoute`	No	State route to filter by. Accepts natural forms — "I-90", "90", "090", "SR 520", "520" — matched case- and space-insensitively to the route number. A route-type prefix is compared only when both sides carry one, so "SR 26" never matches US 26 while a bare "26" matches either. Omit to include all routes.
`endMilepost`	No	End of the milepost range. Matched by extent overlap like startMilepost, so an alert beginning inside the range and continuing past it is returned.
`startMilepost`	No	Start of the milepost range. An alert matches when its extent overlaps the range, so a closure running from MP 10 to MP 30 is returned for a range starting at MP 20. Either bound may be given alone. Alerts reporting no milepost are always included.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`alerts`	No	Matching highway alerts.
`notice`	No	Informational note about the page window, or guidance when no alerts matched the filters or the offset ran past the end.
`hasMore`	No	True when more alerts remain beyond the current page.
`nextOffset`	No	Offset to pass to retrieve the next page, or null when this is the last page.
`totalCount`	No	Total alerts matching the filters across all pages (not just this page).
`appliedFilters`	No	Active filters applied to the alert search.

TDQS

A4.7/5.0

Behavior5/5

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

It discloses useful runtime behavior beyond the readOnlyHint annotation: results are ordered by alertId, paged with a reported next offset, and filters match against the alert's full extent. This aligns with the annotation and adds real operational context.

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?

Three dense, well-ordered sentences cover purpose, filtering, statewide behavior, ordering, and pagination without filler or redundant schema repetition.

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?

With an output schema present, the description does not need to narrate the return shape. It covers selection, filtering, optionality, ordering, and pagination, giving an agent everything needed to invoke the tool correctly.

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 documents all six parameters thoroughly, so the baseline is 3. The description adds tool-level meaning: filters are optional, matching uses the full alert extent, and offset/limit drive pagination across the statewide set.

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 specific verb and resource: 'Returns active WA highway alerts: incidents, construction, closures, and restrictions.' It clearly distinguishes this tool from the ferry, mountain pass, camera, and border wait sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage patterns: filter by route, region, or milepost; omit all filters for a statewide list; and use offset/limit for paging. It does not explicitly name an alternative tool, but no sibling overlaps with this alert-searching function.

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

wsdot_search_camerasSearch Highway CamerasA

Read-only

Inspect

Returns WSDOT highway camera locations, descriptions, and image URLs. Camera images are copyright WSDOT — only metadata and image URLs are returned, not image bytes. Filter by state route ("I-90", "90", "SR 520", or "520" all work), WSDOT region, or milepost range. Results are ordered by cameraId and paged — pass offset/limit to page through the full set (the notice reports the next offset).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum cameras to return in this page (1–500). Defaults to 50.
`offset`	No	Zero-based index of the first camera to return, for paging. Defaults to 0.
`region`	No	WSDOT region code: NW (Northwest), SW (Southwest), OL (Olympic), ER (Eastern), SC (South Central), OS (Olympic South), NC (North Central), or WA (statewide). Matching is case-insensitive.
`stateRoute`	No	State route to filter by. Accepts natural forms — "I-90", "90", "090", "SR 520", "520" — matched case- and space-insensitively to the route number. Camera road names carry a route-type prefix, which is compared when the filter carries one too: "SR 26" excludes US 26, while a bare "26" returns both. A lettered suffix is part of the route, so "US 97" excludes US 97A. Omit to include all routes.
`endMilepost`	No	End of milepost range to filter cameras.
`startMilepost`	No	Start of milepost range to filter cameras.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Informational note about the page window, copyright, or empty results. Absent when not applicable.
`cameras`	No	Camera metadata and image URLs. Images are copyright WSDOT.
`hasMore`	No	True when more cameras remain beyond the current page.
`nextOffset`	No	Offset to pass to retrieve the next page, or null when this is the last page.
`totalCount`	No	Total cameras matching the filters across all pages (not just this page).
`appliedFilters`	No	Active filters applied to the camera search.

TDQS

A4.2/5.0

Behavior4/5

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

The readOnlyHint annotation already signals a safe read operation. The description adds valuable behavioral details: it discloses copyright and that image bytes are not returned, and it explains that results are ordered by cameraId and paged with the next offset reported. These details go beyond the annotation and help the agent set expectations about output.

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 two sentences with no filler. It front-loads the core purpose and limitations, then explains filtering and paging. Every clause adds information an agent needs, making it highly efficient and well-structured.

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 search tool with 6 parameters, all covered by schema, and an output schema present, the description covers the essential behaviors: what is returned, filtering options, ordering, and paging. It does not detail output fields, but that is the output schema's role. The description is complete for invocation purposes.

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?

Schema description coverage is 100%, so the baseline is 3. The description repeats some filter examples already present in the schema (e.g., route formats) but does not add new semantic meaning beyond what the schema already documents. It does not clarify parameter interplay beyond what schema covers, so it meets the baseline but does not exceed it.

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 explicitly states the tool 'Returns WSDOT highway camera locations, descriptions, and image URLs' and clarifies that only metadata and URLs are returned, not image bytes. It clearly distinguishes this from sibling tools focused on ferries, tolls, travel times, etc. The verb 'search' in the name and the description's filter options make the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on how to use the tool: filter by state route, region, or milepost range, and page with offset/limit. It gives examples of route formats ('I-90', '90', 'SR 520', '520') and notes the paging mechanism. It does not explicitly name alternatives or state when not to use it, but given the sibling set, it is self-evident that this is the only camera-related tool.

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.

5 tool updatesSep 20, 2026
- Changedwsdot_get_terminal_space2 fields changed
  - removedOutput schema / properties / nextOffset / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - addedOutput schema / properties / nextOffset / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- Changedwsdot_get_toll_rates2 fields changed
  - removedOutput schema / properties / nextOffset / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - addedOutput schema / properties / nextOffset / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- Changedwsdot_get_travel_times2 fields changed
  - removedOutput schema / properties / nextOffset / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - addedOutput schema / properties / nextOffset / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- Changedwsdot_search_alerts2 fields changed
  - removedOutput schema / properties / nextOffset / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - addedOutput schema / properties / nextOffset / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- Changedwsdot_search_cameras2 fields changed
  - removedOutput schema / properties / nextOffset / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - addedOutput schema / properties / nextOffset / type
```
Added value: +[
+  "number",
+  "null"
+]
```

12 tool updatesAug 25, 2026

Changedwsdot_get_border_waits6 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": [
+      "crossings",
+      "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`: WSDOT Traffic API is unreachable or returns a non-2xx response after retries. `invalid_access_code`: WSDOT 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: -[
-  "crossings",
-  "totalCount"
-]

Changedwsdot_get_ferry_alerts6 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": [
+      "alerts",
+      "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: -[
-  "alerts",
-  "totalCount"
-]

Changedwsdot_get_ferry_routes6 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": [
+      "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"
-]

Changedwsdot_get_ferry_schedule6 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"
-]

Changedwsdot_get_ferry_terminals6 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": [
+      "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"
-]

Changedwsdot_get_mountain_passes6 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": [
+      "passes",
+      "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`: WSDOT Traffic API is unreachable or returns a non-2xx response after retries. `invalid_access_code`: WSDOT 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: -[
-  "passes",
-  "totalCount"
-]

Changedwsdot_get_terminal_space6 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": [
+      "terminals",
+      "totalCount",
+      "nextOffset",
+      "hasMore"
+    ]
+  },
+  {
+    "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",
-  "nextOffset",
-  "hasMore"
-]

Changedwsdot_get_toll_rates6 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": [
+      "rates",
+      "totalCount",
+      "nextOffset",
+      "hasMore"
+    ]
+  },
+  {
+    "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`: WSDOT Traffic API is unreachable or returns a non-2xx response after retries. `invalid_access_code`: WSDOT 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: -[
-  "rates",
-  "totalCount",
-  "nextOffset",
-  "hasMore"
-]

Changedwsdot_get_travel_times6 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": [
+      "corridors",
+      "totalCount",
+      "nextOffset",
+      "hasMore"
+    ]
+  },
+  {
+    "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`: WSDOT Traffic API is unreachable or returns a non-2xx response after retries. `invalid_access_code`: WSDOT 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: -[
-  "corridors",
-  "totalCount",
-  "nextOffset",
-  "hasMore"
-]

Changedwsdot_get_vessel_locations6 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": [
+      "vessels",
+      "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: -[
-  "vessels",
-  "totalCount"
-]

Changedwsdot_search_alerts6 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": [
+      "alerts",
+      "totalCount",
+      "nextOffset",
+      "hasMore",
+      "appliedFilters"
+    ]
+  },
+  {
+    "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`: WSDOT Traffic API is unreachable or returns a non-2xx response after retries. `invalid_access_code`: WSDOT 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: -[
-  "alerts",
-  "totalCount",
-  "nextOffset",
-  "hasMore",
-  "appliedFilters"
-]

Changedwsdot_search_cameras6 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": [
+      "cameras",
+      "totalCount",
+      "nextOffset",
+      "hasMore",
+      "appliedFilters"
+    ]
+  },
+  {
+    "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`: WSDOT Traffic API is unreachable or returns a non-2xx response after retries. `invalid_access_code`: WSDOT 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: -[
-  "cameras",
-  "totalCount",
-  "nextOffset",
-  "hasMore",
-  "appliedFilters"
-]

1 tool updateJul 31, 2026

Changedwsdot_get_ferry_schedule2 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."

4 tool updatesJul 31, 2026

Changedwsdot_get_terminal_space7 fields changed

addedInput schema / properties / limit

Added value: +{
+  "description": "Maximum terminals to return in this page (1–20). Defaults to 5. Counts terminals, not sailings.",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Zero-based index of the first terminal to return, for paging. Defaults to 0.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / hasMore

Added value: +{
+  "description": "True when more terminals remain beyond the current page.",
+  "type": "boolean"
+}

addedOutput schema / properties / nextOffset

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Offset to pass to retrieve the next page, or null when this is the last page."
+}

changedOutput schema / properties / notice / description

Previous value: -"Optional guidance when no terminal space data is available or the filter matched nothing. Absent on normal results."New value: +"Informational note about the page window, or guidance when no terminal space data is available, the filter matched nothing, or the offset ran past the end."

changedOutput schema / properties / totalCount / description

Previous value: -"Number of terminals returned."New value: +"Total terminals matching the filter across all pages (not just this page). Counts terminals, not sailings."

changedOutput schema / required

Previous value: -[
-  "terminals",
-  "totalCount"
-]New value: +[
+  "terminals",
+  "totalCount",
+  "nextOffset",
+  "hasMore"
+]

Changedwsdot_get_toll_rates7 fields changed

addedInput schema / properties / limit

Added value: +{
+  "description": "Maximum toll rates to return in this page (1–500). Defaults to 50.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Zero-based index of the first toll rate to return, for paging. Defaults to 0.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / hasMore

Added value: +{
+  "description": "True when more toll rates remain beyond the current page.",
+  "type": "boolean"
+}

addedOutput schema / properties / nextOffset

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Offset to pass to retrieve the next page, or null when this is the last page."
+}

changedOutput schema / properties / notice / description

Previous value: -"Optional notice when no toll rate data is available. Absent on normal results."New value: +"Informational note about the page window, or guidance when no toll rate data is available or the offset ran past the end."

changedOutput schema / properties / totalCount / description

Previous value: -"Total number of toll rate entries returned."New value: +"Total toll rate entries across all pages (not just this page)."

changedOutput schema / required

Previous value: -[
-  "rates",
-  "totalCount"
-]New value: +[
+  "rates",
+  "totalCount",
+  "nextOffset",
+  "hasMore"
+]

Changedwsdot_get_travel_times7 fields changed

addedInput schema / properties / limit

Added value: +{
+  "description": "Maximum corridors to return in this page (1–500). Defaults to 50.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Zero-based index of the first corridor to return, for paging. Defaults to 0.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / hasMore

Added value: +{
+  "description": "True when more corridors remain beyond the current page.",
+  "type": "boolean"
+}

addedOutput schema / properties / nextOffset

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Offset to pass to retrieve the next page, or null when this is the last page."
+}

changedOutput schema / properties / notice / description

Previous value: -"Optional guidance when no corridors matched the route filter. Absent when results are returned."New value: +"Informational note about the page window, or guidance when no corridors matched the route filter or the offset ran past the end."

changedOutput schema / properties / totalCount / description

Previous value: -"Total number of corridors returned."New value: +"Total corridors matching the filter across all pages (not just this page)."

changedOutput schema / required

Previous value: -[
-  "corridors",
-  "totalCount"
-]New value: +[
+  "corridors",
+  "totalCount",
+  "nextOffset",
+  "hasMore"
+]

Changedwsdot_search_alerts7 fields changed

addedInput schema / properties / limit

Added value: +{
+  "description": "Maximum alerts to return in this page (1–500). Defaults to 50.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Zero-based index of the first alert to return, for paging. Defaults to 0.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / hasMore

Added value: +{
+  "description": "True when more alerts remain beyond the current page.",
+  "type": "boolean"
+}

addedOutput schema / properties / nextOffset

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Offset to pass to retrieve the next page, or null when this is the last page."
+}

changedOutput schema / properties / notice / description

Previous value: -"Optional guidance when no alerts matched — suggests broadening or removing filters. Absent when results are returned."New value: +"Informational note about the page window, or guidance when no alerts matched the filters or the offset ran past the end."

changedOutput schema / properties / totalCount / description

Previous value: -"Total number of alerts returned."New value: +"Total alerts matching the filters across all pages (not just this page)."

changedOutput schema / required

Previous value: -[
-  "alerts",
-  "totalCount",
-  "appliedFilters"
-]New value: +[
+  "alerts",
+  "totalCount",
+  "nextOffset",
+  "hasMore",
+  "appliedFilters"
+]

2 tool updatesJul 31, 2026

Changedwsdot_get_ferry_alerts6 fields changed

addedOutput schema / properties / alerts / items / properties / affectsAllRoutes

Added value: +{
+  "description": "True when the alert applies fleet-wide. A fleet-wide alert need not enumerate routes, so while this is true an empty impactedRouteIds means every route rather than none.",
+  "type": "boolean"
+}

changedOutput schema / properties / alerts / items / properties / alertDescription / description

Previous value: -"Description of the alert or disruption."New value: +"One-line summary of the alert or disruption, as shown on the route pages. Falls back to the title when upstream publishes no summary."

addedOutput schema / properties / alerts / items / properties / alertTitle

Added value: +{
+  "description": "The bulletin's own title.",
+  "type": "string"
+}

addedOutput schema / properties / alerts / items / properties / alertType

Added value: +{
+  "description": "Alert kind as WSF categorizes it, e.g. \"All Alerts\".",
+  "type": "string"
+}

addedOutput schema / properties / alerts / items / properties / bulletinText

Added value: +{
+  "description": "Full bulletin body as plain text, normalized from the upstream HTML — links are rendered inline as \"link text (url)\". Detail that appears nowhere else, such as a replacement sailing, lives here.",
+  "type": "string"
+}

changedOutput schema / properties / alerts / items / properties / impactedRouteIds / description

Previous value: -"Route IDs affected by this alert. Cross-reference with wsdot_get_ferry_routes to get route names; some seasonal or interisland route IDs may not be listed there for a given date."New value: +"Route IDs affected by this alert. Cross-reference with wsdot_get_ferry_routes to get route names; some seasonal or interisland route IDs may not be listed there for a given date. Empty means no specific routes unless affectsAllRoutes is true, which makes it fleet-wide."

Changedwsdot_search_alerts2 fields changed

changedOutput schema / properties / alerts / items / properties / extendedDescription / description

Previous value: -"Full description of the alert."New value: +"Full description of the alert, normalized to plain text on the same terms as headlineDescription. Often absent — most alerts carry only a headline."

changedOutput schema / properties / alerts / items / properties / headlineDescription / description

Previous value: -"Short summary of the alert."New value: +"Short summary of the alert, as plain text. Upstream authors these in a rich-text editor, so any markup is normalized away and a link is rendered inline as \"link text (url)\"."

5 tool updatesJul 31, 2026

Changedwsdot_get_ferry_schedule1 field changed
- removedOutput schema / properties / sailings / items / properties / isCancelled
```
Removed value: -{
-  "description": "Whether this sailing is cancelled.",
-  "type": "boolean"
-}
```

Changedwsdot_get_terminal_space7 fields changed

addedOutput schema / properties / terminals / items / properties / departingSpaces / items / properties / arrivingTerminalIds

Added value: +{
+  "description": "Numeric IDs of the terminals this sailing serves — the destinations. Pass one to wsdot_get_ferry_schedule as arrivingTerminalId, or resolve names with wsdot_get_ferry_terminals.",
+  "items": {
+    "type": "number"
+  },
+  "type": "array"
+}

removedOutput schema / properties / terminals / items / properties / departingSpaces / items / properties / arrivingTerminalName
```
Removed value: -{
-  "description": "Destination terminal name.",
-  "type": "string"
-}
```

addedOutput schema / properties / terminals / items / properties / departingSpaces / items / properties / displayDriveUpSpace

Added value: +{
+  "description": "Whether WSF publishes a drive-up count for this sailing. False means driveUpSpaceCount is not reported, not that the lane is empty.",
+  "type": "boolean"
+}

added

Output schema / properties / terminals / items / properties / departingSpaces / items / properties / displayReservableSpace

Added value: +{
+  "description": "Whether this sailing takes vehicle reservations. False means reservableSpaceCount does not apply.",
+  "type": "boolean"
+}

changed

Output schema / properties / terminals / items / properties / departingSpaces / items / properties / driveUpSpaceCount / description

Previous value: -"Available drive-up vehicle spaces. Zero means full."New value: +"Available drive-up vehicle spaces. Zero means full — oversubscribed sailings report a negative count upstream and are floored to zero here, so this value is never negative."

addedOutput schema / properties / terminals / items / properties / departingSpaces / items / properties / itineraryLabel

Added value: +{
+  "description": "Upstream itinerary string for the sailing, e.g. \"Anacortes -> Friday Harbor\". A display label only — it may name the departing terminal or several stops, so do not read it as the destination.",
+  "type": "string"
+}

changed

Output schema / properties / terminals / items / properties / departingSpaces / items / properties / reservableSpaceCount / description

Previous value: -"Available reservable vehicle spaces."New value: +"Available reservable vehicle spaces, floored at zero like driveUpSpaceCount. Zero means no reservable space remains."

Changedwsdot_get_travel_times4 fields changed

changedInput schema / properties / route / description

Previous value: -"Optional text filter applied to corridor names (e.g. \"I-5\", \"SR 520\", \"I-405\"). Case-insensitive. Omit to return all corridors."New value: +"Optional filter. A route designation — \"I-5\", \"5\", \"005\", \"SR 520\", \"520\" — matches every corridor whose start or end point is on that route, whichever form the feed reports. Any text also matches the corridor name as a case-insensitive substring, so \"Everett\" finds the Seattle-Everett corridors. Omit to return all corridors."

changedOutput schema / properties / corridors / items / properties / averageTimeInMinutes / description

Previous value: -"Historical average travel time in minutes."New value: +"Historical average travel time in minutes. Absent when WSDOT reports no measurement for the corridor."

changedOutput schema / properties / corridors / items / properties / currentTimeInMinutes / description

Previous value: -"Current travel time in minutes."New value: +"Current travel time in minutes. Absent when WSDOT reports no measurement for the corridor — a reversible express lane closed in this direction reports none."

changedOutput schema / properties / corridors / items / properties / delayInMinutes / description

Previous value: -"Delay above average in minutes. Positive means congestion."New value: +"Delay above average in minutes. Positive means congestion. Absent when either travel time is unavailable."

Changedwsdot_search_alerts3 fields changed

changedInput schema / properties / endMilepost / description

Previous value: -"End of milepost range to filter alerts."New value: +"End of the milepost range. Matched by extent overlap like startMilepost, so an alert beginning inside the range and continuing past it is returned."

changedInput schema / properties / startMilepost / description

Previous value: -"Start of milepost range to filter alerts."New value: +"Start of the milepost range. An alert matches when its extent overlaps the range, so a closure running from MP 10 to MP 30 is returned for a range starting at MP 20. Either bound may be given alone. Alerts reporting no milepost are always included."

changedInput schema / properties / stateRoute / description

Previous value: -"State route to filter by. Accepts natural forms — \"I-90\", \"90\", \"090\", \"SR 520\", \"520\" — matched case- and space-insensitively to the canonical WSDOT route number. Omit to include all routes."New value: +"State route to filter by. Accepts natural forms — \"I-90\", \"90\", \"090\", \"SR 520\", \"520\" — matched case- and space-insensitively to the route number. A route-type prefix is compared only when both sides carry one, so \"SR 26\" never matches US 26 while a bare \"26\" matches either. Omit to include all routes."

Changedwsdot_search_cameras1 field changed

changedInput schema / properties / stateRoute / description

Previous value: -"State route to filter by. Accepts natural forms — \"I-90\", \"90\", \"090\", \"SR 520\", \"520\" — matched case- and space-insensitively to the canonical WSDOT route number. Omit to include all routes."New value: +"State route to filter by. Accepts natural forms — \"I-90\", \"90\", \"090\", \"SR 520\", \"520\" — matched case- and space-insensitively to the route number. Camera road names carry a route-type prefix, which is compared when the filter carries one too: \"SR 26\" excludes US 26, while a bare \"26\" returns both. A lettered suffix is part of the route, so \"US 97\" excludes US 97A. Omit to include all routes."

2 tool updatesJul 12, 2026

Changedwsdot_search_alerts1 field changed

changedInput schema / properties / stateRoute / description

Previous value: -"Zero-padded 3-digit state route number (e.g. \"005\" for I-5, \"090\" for I-90, \"520\" for SR 520)."New value: +"State route to filter by. Accepts natural forms — \"I-90\", \"90\", \"090\", \"SR 520\", \"520\" — matched case- and space-insensitively to the canonical WSDOT route number. Omit to include all routes."

Changedwsdot_search_cameras8 fields changed

addedInput schema / properties / limit

Added value: +{
+  "description": "Maximum cameras to return in this page (1–500). Defaults to 50.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Zero-based index of the first camera to return, for paging. Defaults to 0.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

changedInput schema / properties / stateRoute / description

Previous value: -"Zero-padded 3-digit state route number (e.g. \"005\" for I-5, \"090\" for I-90)."New value: +"State route to filter by. Accepts natural forms — \"I-90\", \"90\", \"090\", \"SR 520\", \"520\" — matched case- and space-insensitively to the canonical WSDOT route number. Omit to include all routes."

addedOutput schema / properties / hasMore

Added value: +{
+  "description": "True when more cameras remain beyond the current page.",
+  "type": "boolean"
+}

addedOutput schema / properties / nextOffset

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Offset to pass to retrieve the next page, or null when this is the last page."
+}

changedOutput schema / properties / notice / description

Previous value: -"Informational note about result truncation, copyright, or empty results. Absent when not applicable."New value: +"Informational note about the page window, copyright, or empty results. Absent when not applicable."

changedOutput schema / properties / totalCount / description

Previous value: -"Total number of cameras returned."New value: +"Total cameras matching the filters across all pages (not just this page)."

changedOutput schema / required

Previous value: -[
-  "cameras",
-  "totalCount",
-  "appliedFilters"
-]New value: +[
+  "cameras",
+  "totalCount",
+  "nextOffset",
+  "hasMore",
+  "appliedFilters"
+]

7 tool updatesJun 9, 2026

Changedwsdot_get_border_waits6 fields changed

changedOutput schema / properties / crossings / items / properties / crossingName / description

Previous value: -"Name of the border crossing."New value: +"Route-code crossing identifier (e.g. \"I5\", \"I5Nexus\", \"SR539\", \"SR9\"). See location.description for the readable name."

changedOutput schema / properties / crossings / items / properties / location / description

Previous value: -"Geographic location of the crossing."New value: +"Geographic location and readable name of the crossing."

addedOutput schema / properties / crossings / items / properties / location / properties / description

Added value: +{
+  "description": "Readable crossing/lane name (e.g. \"I-5 General Purpose\", \"I-5 Nexus Lane\").",
+  "type": "string"
+}

changedOutput schema / properties / crossings / items / properties / location / properties / direction / description

Previous value: -"Travel direction."New value: +"Travel direction code (N/S/E/W/B); frequently null for border crossings."

changedOutput schema / properties / crossings / items / properties / updateTime / description

Previous value: -"When this wait time was last updated."New value: +"When this wait time was last updated (ISO 8601)."

changedOutput schema / properties / crossings / items / properties / waitTimeInMinutes / description

Previous value: -"Current vehicle wait time in minutes."New value: +"Current vehicle wait time in minutes. Omitted when the crossing reports no data (WSDOT emits a -1 sentinel for closed/unmonitored crossings)."

Changedwsdot_get_ferry_alerts1 field changed

changedOutput schema / properties / alerts / items / properties / impactedRouteIds / description

Previous value: -"Route IDs affected by this alert. Cross-reference with wsdot_get_ferry_routes to get route names."New value: +"Route IDs affected by this alert. Cross-reference with wsdot_get_ferry_routes to get route names; some seasonal or interisland route IDs may not be listed there for a given date."

Changedwsdot_get_mountain_passes11 fields changed

changedOutput schema / properties / passes / items / properties / dateUpdated / description

Previous value: -"Timestamp of the last condition update."New value: +"Timestamp of the last condition update (ISO 8601)."

changedOutput schema / properties / passes / items / properties / restrictionOne / description

Previous value: -"Primary travel restriction, if any."New value: +"Primary travel/traction restriction (typically one direction of travel)."

removedOutput schema / properties / passes / items / properties / restrictionOne / properties / comment

Removed value: -{
-  "description": "Restriction description (e.g. \"Traction Tires Required\").",
-  "type": "string"
-}

addedOutput schema / properties / passes / items / properties / restrictionOne / properties / text

Added value: +{
+  "description": "Restriction / traction-law text (e.g. \"Traction Tires Required, Chains Required (Except All Wheel Drive)\"). Reads \"No current information available\" or \"No restrictions\" when nothing is in effect.",
+  "type": "string"
+}

addedOutput schema / properties / passes / items / properties / restrictionOne / properties / travelDirection

Added value: +{
+  "description": "Direction this restriction applies to (e.g. \"Northbound\", \"Eastbound\", \"Both directions\").",
+  "type": "string"
+}

removedOutput schema / properties / passes / items / properties / restrictionOne / properties / type
```
Removed value: -{
-  "description": "Restriction type code.",
-  "type": "string"
-}
```

changedOutput schema / properties / passes / items / properties / restrictionTwo / description

Previous value: -"Secondary travel restriction, if any."New value: +"Secondary travel/traction restriction (typically the opposite direction)."

removedOutput schema / properties / passes / items / properties / restrictionTwo / properties / comment
```
Removed value: -{
-  "description": "Restriction description.",
-  "type": "string"
-}
```

addedOutput schema / properties / passes / items / properties / restrictionTwo / properties / text

Added value: +{
+  "description": "Restriction / traction-law text for the second direction.",
+  "type": "string"
+}

addedOutput schema / properties / passes / items / properties / restrictionTwo / properties / travelDirection

Added value: +{
+  "description": "Direction this restriction applies to (e.g. \"Southbound\", \"Westbound\").",
+  "type": "string"
+}

removedOutput schema / properties / passes / items / properties / restrictionTwo / properties / type
```
Removed value: -{
-  "description": "Restriction type code.",
-  "type": "string"
-}
```

Changedwsdot_get_toll_rates2 fields changed

changedOutput schema / properties / rates / items / properties / timeUpdated / description

Previous value: -"When this toll rate was last updated."New value: +"When this toll rate was last updated (ISO 8601)."

changedOutput schema / properties / rates / items / properties / travelDirection / description

Previous value: -"Travel direction for this toll segment (e.g. \"N\", \"S\", \"E\", \"W\")."New value: +"Travel direction code for this toll segment: N (north), S (south), E (east), W (west)."

Changedwsdot_get_travel_times3 fields changed
- changedOutput schema / properties / corridors / items / properties / endPoint / properties / direction / description
```
Previous value: -"Travel direction."New value: +"Travel direction code: N (north), S (south), E (east), W (west)."
```
- changedOutput schema / properties / corridors / items / properties / startPoint / properties / direction / description
```
Previous value: -"Travel direction."New value: +"Travel direction code: N (north), S (south), E (east), W (west)."
```
- changedOutput schema / properties / corridors / items / properties / timeUpdated / description
```
Previous value: -"When the travel time data was last updated."New value: +"When the travel time data was last updated (ISO 8601)."
```

Changedwsdot_search_alerts5 fields changed

changedOutput schema / properties / alerts / items / properties / endRoadwayLocation / properties / direction / description

Previous value: -"Travel direction."New value: +"Travel direction code: N/S/E/W, B (both directions), A (alternating); may appear as NB/SB/EB/WB."

changedOutput schema / properties / alerts / items / properties / endTime / description

Previous value: -"When the event is expected to end."New value: +"When the event is expected to end (ISO 8601)."

changedOutput schema / properties / alerts / items / properties / lastUpdatedTime / description

Previous value: -"When this alert was last updated."New value: +"When this alert was last updated (ISO 8601)."

changedOutput schema / properties / alerts / items / properties / startRoadwayLocation / properties / direction / description

Previous value: -"Travel direction."New value: +"Travel direction code: N/S/E/W, B (both directions), A (alternating); may appear as NB/SB/EB/WB."

changedOutput schema / properties / alerts / items / properties / startTime / description

Previous value: -"When the event started or is scheduled to start."New value: +"When the event started or is scheduled to start (ISO 8601)."

Changedwsdot_search_cameras1 field changed

changedOutput schema / properties / cameras / items / properties / direction / description

Previous value: -"Traffic direction monitored."New value: +"Traffic-direction code monitored: N/S/E/W, B (both), NB/SB/EB/WB. Some sites use other location-specific markers."

3 tool updatesJun 8, 2026

Changedwsdot_get_toll_rates8 fields changed

addedOutput schema / properties / rates / items / properties / endLatitude

Added value: +{
+  "description": "Latitude of the segment end point.",
+  "type": "number"
+}

addedOutput schema / properties / rates / items / properties / endLongitude

Added value: +{
+  "description": "Longitude of the segment end point.",
+  "type": "number"
+}

changedOutput schema / properties / rates / items / properties / message / description

Previous value: -"Dynamic message shown on toll sign."New value: +"Dynamic message associated with this toll."

removedOutput schema / properties / rates / items / properties / signText

Removed value: -{
-  "description": "Text displayed on the toll rate sign.",
-  "type": "string"
-}

addedOutput schema / properties / rates / items / properties / startLatitude

Added value: +{
+  "description": "Latitude of the segment start point.",
+  "type": "number"
+}

addedOutput schema / properties / rates / items / properties / startLongitude

Added value: +{
+  "description": "Longitude of the segment start point.",
+  "type": "number"
+}

removedOutput schema / properties / rates / items / properties / tollCondition

Removed value: -{
-  "description": "Numeric toll condition code.",
-  "type": "number"
-}

addedOutput schema / properties / rates / items / properties / travelDirection

Added value: +{
+  "description": "Travel direction for this toll segment (e.g. \"N\", \"S\", \"E\", \"W\").",
+  "type": "string"
+}

Changedwsdot_search_alerts1 field changed

changedInput schema / properties / region / description

Previous value: -"WSDOT region name: Northwest, Olympic, Southwest, South Central, North Central, or Eastern."New value: +"WSDOT region name as it appears in alert data: \"Northwest\", \"Olympic\", \"Southwest\", \"South Central\", \"North Central\", or \"Eastern\". Matching is case-insensitive."

Changedwsdot_search_cameras1 field changed

changedInput schema / properties / region / description

Previous value: -"WSDOT region name: Northwest, Olympic, Southwest, South Central, North Central, or Eastern."New value: +"WSDOT region code: NW (Northwest), SW (Southwest), OL (Olympic), ER (Eastern), SC (South Central), OS (Olympic South), NC (North Central), or WA (statewide). Matching is case-insensitive."

12 tool updatesMay 30, 2026

Changedwsdot_get_border_waits1 field changed

addedOutput schema / properties / notice

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

Changedwsdot_get_ferry_alerts1 field changed

addedOutput schema / properties / notice

Added value: +{
+  "description": "Optional notice when no alerts are active. Absent when alerts are present.",
+  "type": "string"
+}

Changedwsdot_get_ferry_routes1 field changed

addedOutput schema / properties / notice

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

Changedwsdot_get_ferry_schedule2 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"
+]

Changedwsdot_get_ferry_terminals2 fields changed

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

Changedwsdot_get_mountain_passes3 fields changed

addedOutput schema / properties / notice

Added value: +{
+  "description": "Optional notice when no pass data is available — e.g. API temporarily unavailable. Absent on normal results.",
+  "type": "string"
+}

addedOutput schema / properties / totalCount

Added value: +{
+  "description": "Total number of passes returned.",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "passes"
-]New value: +[
+  "passes",
+  "totalCount"
+]

Changedwsdot_get_terminal_space2 fields changed

addedOutput schema / properties / notice

Added value: +{
+  "description": "Optional guidance when no terminal space data is available or the filter matched nothing. Absent on normal results.",
+  "type": "string"
+}

addedOutput schema / properties / terminalFilter

Added value: +{
+  "description": "The terminal ID filter applied, or absent if no filter was used.",
+  "type": "number"
+}

Changedwsdot_get_toll_rates1 field changed

addedOutput schema / properties / notice

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

Changedwsdot_get_travel_times2 fields changed

addedOutput schema / properties / notice

Added value: +{
+  "description": "Optional guidance when no corridors matched the route filter. Absent when results are returned.",
+  "type": "string"
+}

addedOutput schema / properties / routeFilter

Added value: +{
+  "description": "The route name filter applied (lowercased), or absent if no filter was used.",
+  "type": "string"
+}

Changedwsdot_get_vessel_locations1 field changed

addedOutput schema / properties / notice

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

Changedwsdot_search_alerts3 fields changed

addedOutput schema / properties / appliedFilters

Added value: +{
+  "additionalProperties": false,
+  "description": "Active filters applied to the alert search.",
+  "properties": {
+    "endMilepost": {
+      "description": "End milepost filter applied.",
+      "type": "number"
+    },
+    "region": {
+      "description": "Region filter applied.",
+      "type": "string"
+    },
+    "startMilepost": {
+      "description": "Start milepost filter applied.",
+      "type": "number"
+    },
+    "stateRoute": {
+      "description": "State route filter applied.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Optional guidance when no alerts matched — suggests broadening or removing filters. Absent when results are returned.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "alerts",
-  "totalCount"
-]New value: +[
+  "alerts",
+  "totalCount",
+  "appliedFilters"
+]

Changedwsdot_search_cameras4 fields changed

addedOutput schema / properties / appliedFilters

Added value: +{
+  "additionalProperties": false,
+  "description": "Active filters applied to the camera search.",
+  "properties": {
+    "endMilepost": {
+      "description": "End milepost filter applied.",
+      "type": "number"
+    },
+    "region": {
+      "description": "Region filter applied.",
+      "type": "string"
+    },
+    "startMilepost": {
+      "description": "Start milepost filter applied.",
+      "type": "number"
+    },
+    "stateRoute": {
+      "description": "State route filter applied.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

removedOutput schema / properties / note

Removed value: -{
-  "description": "Informational note about result truncation or copyright.",
-  "type": "string"
-}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Informational note about result truncation, copyright, or empty results. Absent when not applicable.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "cameras",
-  "totalCount"
-]New value: +[
+  "cameras",
+  "totalCount",
+  "appliedFilters"
+]

12 tool updatesMay 25, 2026
- First observedwsdot_get_border_waits
- First observedwsdot_get_ferry_alerts
- First observedwsdot_get_ferry_routes
- First observedwsdot_get_ferry_schedule
- First observedwsdot_get_ferry_terminals
- First observedwsdot_get_mountain_passes
- First observedwsdot_get_terminal_space
- First observedwsdot_get_toll_rates
- First observedwsdot_get_travel_times
- First observedwsdot_get_vessel_locations
- First observedwsdot_search_alerts
- First observedwsdot_search_cameras

Related MCP Connectors

commutescout A
io.github.nicglazkov
Live road conditions in 37 US states: incidents, closures, chain controls, cameras, wildfires.
Travel & Transportation Location Services
1024
Faa Delays A
io.github.pipeworx-io
FAA Delays MCP — live US airport operational status (FAA, free, no auth).
Travel & Transportation Government Data
2
Wmata A
io.github.pipeworx-io
Washington Metro real-time + static rail/bus data. Free key required.
Travel & Transportation Location Services
462
DataQuoll AOAuth
io.dataquoll
Australian public data as MCP tools: incidents, gauges, declarations, industry calendars, archive.
Open Data Government Data Weather Services
1

Related MCP Servers

CommuteScout
Travel & Transportation Location Services
nicglazkov
A
license
A
quality
A
maintenance
Provides live California road conditions, route planning, and an AI assistant over MCP, enabling natural-language queries about traffic, closures, chain controls, and more.
Updated a day ago (2026-09-23 02:24 UTC)
10
4
MIT
DriveBC MCP Server
Location Services Travel & Transportation Weather Services
infil00p
A
license
B
quality
D
maintenance
Provides real-time access to BC highway conditions, road closures, weather alerts, and traffic incidents through the Open511-DriveBC API with smart caching.
Updated 9 months ago (2025-12-14 02:55 UTC)
4
MIT
livetrafficcam-mcp
Travel & Transportation Location Services Government Data
bzsasson
A
license
A
quality
A
maintenance
Enables querying verified-live US traffic cameras by state, route, or named corridor, with camera status and state fleet uptime from official DOT feeds.
Updated 6 days ago (2026-09-18 13:16 UTC)
5
23 npm
MIT
anwb-mcp
Travel & Transportation Location Services
BartWaardenburg
A
license
A
quality
C
maintenance
MCP server for ANWB traffic information, route planning, and location search in the Netherlands. Provides real-time traffic incidents, route calculation with turn-by-turn directions, and location search via natural language.
Updated 7 months ago (2026-03-06 07:43 UTC)
6
3 npm
MIT

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources