@cyanheads/wsdot-mcp-server 0.2.5 → 0.2.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (59) hide show
  1. package/AGENTS.md +45 -18
  2. package/CLAUDE.md +45 -18
  3. package/README.md +64 -73
  4. package/changelog/0.2.x/0.2.6.md +29 -0
  5. package/changelog/template.md +9 -26
  6. package/dist/index.js +4 -0
  7. package/dist/index.js.map +1 -1
  8. package/dist/mcp-server/tools/definitions/get-border-waits.tool.d.ts +2 -0
  9. package/dist/mcp-server/tools/definitions/get-border-waits.tool.d.ts.map +1 -1
  10. package/dist/mcp-server/tools/definitions/get-border-waits.tool.js +3 -1
  11. package/dist/mcp-server/tools/definitions/get-border-waits.tool.js.map +1 -1
  12. package/dist/mcp-server/tools/definitions/get-ferry-alerts.tool.d.ts +2 -0
  13. package/dist/mcp-server/tools/definitions/get-ferry-alerts.tool.d.ts.map +1 -1
  14. package/dist/mcp-server/tools/definitions/get-ferry-alerts.tool.js +2 -0
  15. package/dist/mcp-server/tools/definitions/get-ferry-alerts.tool.js.map +1 -1
  16. package/dist/mcp-server/tools/definitions/get-ferry-routes.tool.d.ts +2 -0
  17. package/dist/mcp-server/tools/definitions/get-ferry-routes.tool.d.ts.map +1 -1
  18. package/dist/mcp-server/tools/definitions/get-ferry-routes.tool.js +3 -1
  19. package/dist/mcp-server/tools/definitions/get-ferry-routes.tool.js.map +1 -1
  20. package/dist/mcp-server/tools/definitions/get-ferry-schedule.tool.d.ts +2 -0
  21. package/dist/mcp-server/tools/definitions/get-ferry-schedule.tool.d.ts.map +1 -1
  22. package/dist/mcp-server/tools/definitions/get-ferry-schedule.tool.js +4 -6
  23. package/dist/mcp-server/tools/definitions/get-ferry-schedule.tool.js.map +1 -1
  24. package/dist/mcp-server/tools/definitions/get-ferry-terminals.tool.d.ts +2 -0
  25. package/dist/mcp-server/tools/definitions/get-ferry-terminals.tool.d.ts.map +1 -1
  26. package/dist/mcp-server/tools/definitions/get-ferry-terminals.tool.js +3 -1
  27. package/dist/mcp-server/tools/definitions/get-ferry-terminals.tool.js.map +1 -1
  28. package/dist/mcp-server/tools/definitions/get-mountain-passes.tool.d.ts +2 -0
  29. package/dist/mcp-server/tools/definitions/get-mountain-passes.tool.d.ts.map +1 -1
  30. package/dist/mcp-server/tools/definitions/get-mountain-passes.tool.js +3 -1
  31. package/dist/mcp-server/tools/definitions/get-mountain-passes.tool.js.map +1 -1
  32. package/dist/mcp-server/tools/definitions/get-terminal-space.tool.d.ts +2 -0
  33. package/dist/mcp-server/tools/definitions/get-terminal-space.tool.d.ts.map +1 -1
  34. package/dist/mcp-server/tools/definitions/get-terminal-space.tool.js +2 -0
  35. package/dist/mcp-server/tools/definitions/get-terminal-space.tool.js.map +1 -1
  36. package/dist/mcp-server/tools/definitions/get-toll-rates.tool.d.ts +2 -0
  37. package/dist/mcp-server/tools/definitions/get-toll-rates.tool.d.ts.map +1 -1
  38. package/dist/mcp-server/tools/definitions/get-toll-rates.tool.js +3 -1
  39. package/dist/mcp-server/tools/definitions/get-toll-rates.tool.js.map +1 -1
  40. package/dist/mcp-server/tools/definitions/get-travel-times.tool.d.ts +2 -0
  41. package/dist/mcp-server/tools/definitions/get-travel-times.tool.d.ts.map +1 -1
  42. package/dist/mcp-server/tools/definitions/get-travel-times.tool.js +2 -0
  43. package/dist/mcp-server/tools/definitions/get-travel-times.tool.js.map +1 -1
  44. package/dist/mcp-server/tools/definitions/get-vessel-locations.tool.d.ts +2 -0
  45. package/dist/mcp-server/tools/definitions/get-vessel-locations.tool.d.ts.map +1 -1
  46. package/dist/mcp-server/tools/definitions/get-vessel-locations.tool.js +3 -1
  47. package/dist/mcp-server/tools/definitions/get-vessel-locations.tool.js.map +1 -1
  48. package/dist/mcp-server/tools/definitions/search-alerts.tool.d.ts +2 -0
  49. package/dist/mcp-server/tools/definitions/search-alerts.tool.d.ts.map +1 -1
  50. package/dist/mcp-server/tools/definitions/search-alerts.tool.js +3 -1
  51. package/dist/mcp-server/tools/definitions/search-alerts.tool.js.map +1 -1
  52. package/dist/mcp-server/tools/definitions/search-cameras.tool.d.ts +2 -0
  53. package/dist/mcp-server/tools/definitions/search-cameras.tool.d.ts.map +1 -1
  54. package/dist/mcp-server/tools/definitions/search-cameras.tool.js +3 -1
  55. package/dist/mcp-server/tools/definitions/search-cameras.tool.js.map +1 -1
  56. package/dist/services/ferry/ferry-service.js +3 -3
  57. package/dist/services/traffic/traffic-service.js +3 -3
  58. package/package.json +10 -9
  59. package/server.json +3 -3
package/AGENTS.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** @cyanheads/wsdot-mcp-server
4
- **Version:** 0.2.5
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.12.3`
6
- **Engines:** Bun ≥1.3.0, Node ≥24.0.0
4
+ **Version:** 0.2.6
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.6`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
7
  **MCP SDK:** `@modelcontextprotocol/server` ^2.0.0 (protocol revisions 2026-07-28 and 2025-*)
8
- **Zod:** ^4.4.3
8
+ **Zod:** ^4.6.5
9
9
 
10
10
  > **Read the framework docs first:** `node_modules/@cyanheads/mcp-ts-core/CLAUDE.md` contains the full API reference — builders, Context, error codes, exports, patterns. This file covers server-specific conventions only.
11
11
 
@@ -18,6 +18,7 @@
18
18
  - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
19
19
  - **Need input the caller didn't supply?** `return ctx.requestInput(...)` and read `ctx.inputs` when the handler is re-entered. Never `await` for user input mid-handler.
20
20
  - **Secrets in env vars only** — never hardcoded.
21
+ - **Cut noise.** Add only what earns its place: no speculative generality, no guards for states the framework already prevents (Zod-validated params, classified errors), no abstraction until a third caller proves it, no option nothing sets.
21
22
  - **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed and close it. Do both — a comment without a close leaves stale issues open; a close without a comment leaves no record of what shipped. The comment is for future readers — state the concrete changes, not the conversation that produced them.
22
23
 
23
24
  ---
@@ -83,6 +84,22 @@ export function getServerConfig() {
83
84
 
84
85
  For env booleans use `z.stringbool()`, never `z.coerce.boolean()` — `Boolean("false")` is `true`, so a coerced flag can't be disabled through the environment. `z.stringbool()` parses `true/false/1/0/yes/no/on/off` and rejects anything else, so `=false` actually disables.
85
86
 
87
+ ### Session posture and shutdown
88
+
89
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
90
+
91
+ ```ts
92
+ await createApp({
93
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
94
+ setup(core) { startMyWatcher(core.config); },
95
+ async teardown() { await stopMyWatcher(); },
96
+ });
97
+ ```
98
+
99
+ `sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the option). Add `require: 'stateful'` when a tool asks the caller for input mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused. This server declares `sessionMode: 'stateless'` — no tool calls `ctx.requestInput`.
100
+
101
+ `teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d timer there. It runs after the transport stops and before the logger closes, on every shutdown path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step never settles within the framework's 10 s ceiling). Neither WSDOT service holds one, so no `teardown` is declared.
102
+
86
103
  ---
87
104
 
88
105
  ## Context
@@ -107,7 +124,7 @@ Handlers receive a unified `ctx` object. Key properties:
107
124
 
108
125
  Handlers throw — the framework catches, classifies, and formats.
109
126
 
110
- **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`data.recovery.hint`, mirrored into `content[]` text); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`) bubble freely and don't need declaring.
127
+ **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable?, severity?, thrownBy? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`data.recovery.hint`, mirrored into `content[]` text unless the message already contains it verbatim); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Forwarding it is lint-enforced per throw site (`error-contract-recovery-unforwarded`). Mark an entry the service layer throws with `thrownBy: 'service'` so `error-contract-unthrown` skips it — lint-only metadata, nothing at runtime reads it. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`, `RequestCancelled`) bubble freely and don't need declaring.
111
128
 
112
129
  ```ts
113
130
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -192,9 +209,9 @@ src/
192
209
 
193
210
  ## Skills
194
211
 
195
- Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry.
212
+ Skills are modular instructions in `framework-skills/` at the project root. Read them directly when a task matches — e.g., `framework-skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry. The directory is deliberately not `skills/`: Claude Code and Codex auto-load a plugin's root `skills/`, so a server that ships `.claude-plugin/` or `.codex-plugin/` would hand these development skills to every agent that installs it. Keep `skills/` free for skills meant for those agents.
196
213
 
197
- **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
214
+ **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `framework-skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
198
215
 
199
216
  Available skills:
200
217
 
@@ -213,8 +230,9 @@ Available skills:
213
230
  | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
214
231
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
215
232
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
216
- | `git-wrapup` | Land working-tree changes as a versioned commit + annotated tag — version bump, changelog, verify, tag. Local only. |
217
- | `release-and-publish` | Push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
233
+ | `git-wrapup` | Land working-tree changes as a commit stack — version bump, changelog, verify, commit by concern, release commit on top. No tag, no push to main; opens the release PR when the project declares release PR mode |
234
+ | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixes as ordinary commits on top of the stack, PR body kept in sync. Release PR mode only |
235
+ | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
218
236
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
219
237
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
220
238
  | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
@@ -233,7 +251,7 @@ Available skills:
233
251
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
234
252
  | `api-workers` | Cloudflare Workers runtime |
235
253
 
236
- **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
254
+ **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `framework-skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
237
255
 
238
256
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
239
257
 
@@ -249,7 +267,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
249
267
  | `bun run rebuild` | Clean + build |
250
268
  | `bun run clean` | Remove build artifacts |
251
269
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
252
- | `bun run audit:refresh` | Delete `bun.lock`, reinstall, and re-run `bun audit`. Use when `devcheck` flags a transitive advisory — Bun's `update` is sticky on transitive resolutions, so the advisory may be a stale-lockfile false positive. If it survives the refresh, it's real. |
270
+ | `bun run audit:fix` | `bun audit fix` — upgrade vulnerable packages to the lowest safe version within existing ranges (`--dry-run` previews, `--latest` rewrites ranges). First response when `devcheck` flags a transitive advisory; then `bun update <name>`, then `bun dedupe` |
271
+ | `bun run audit:refresh` | Delete `bun.lock` and reinstall. Last resort after `audit:fix`, `bun update <name>`, and `bun dedupe` — re-resolves every ranged dep (the framework pin included) and rewrites the lockfile as `lockfileVersion: 2` |
253
272
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
254
273
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
255
274
  | `bun run list-skills` | Print the skill registry |
@@ -263,15 +282,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
263
282
  | `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
264
283
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
265
284
 
285
+ **CI is one file.** `.github/workflows/codeql.yml` (scaffolded) is the only GitHub Actions workflow: CodeQL is GitHub-owned end to end, and the file runs only while the repo's CodeQL *default setup* is turned off. Verification — `devcheck`, tests, the release gates — runs locally; don't add a workflow that re-runs it.
286
+
266
287
  ---
267
288
 
268
289
  ## Bundling
269
290
 
270
- `bun run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
291
+ `bun run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
271
292
 
272
- **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match.
293
+ **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match, that every `user_config` option is wired into `mcp_config.env` as `"X": "${user_config.X}"` (the host substitutes nothing else — `"${X}"` reaches the server as that literal string), and that an optional string option carries `"default": ""`.
273
294
 
274
- **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `skills/polish-docs-meta/references/readme.md`.
295
+ **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `framework-skills/polish-docs-meta/references/readme.md`.
275
296
 
276
297
  ---
277
298
 
@@ -296,12 +317,18 @@ security: false # optional — true ONLY for a source
296
317
 
297
318
  `agent-notes` is an optional free-form field for maintenance agents processing the release downstream. Content here won't appear in the rendered CHANGELOG — it's consumed by agents running the `maintenance` skill. Use it for adoption instructions that don't fit the human-facing sections: new files to create, fields to populate, one-time migration steps. Omit entirely when there's nothing to say.
298
319
 
299
- **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security. Include only sections with entries — don't ship empty headers.
320
+ **Section order:** the Keep a Changelog sequence — Added, Changed, Deprecated, Removed, Fixed, Security — then `Dependencies` last. Include only sections with entries — don't ship empty headers.
300
321
 
301
322
  **Tag annotations** render as GitHub Release bodies via `--notes-from-tag`. They must be structured markdown — never a flat comma-separated string. Subject omits the version number (GitHub prepends it). See `changelog/template.md` for the full format reference.
302
323
 
303
324
  ---
304
325
 
326
+ ## Publishing
327
+
328
+ **Every release goes through a release PR, straight-through** — `git-wrapup`'s "Release PR mode", mode `straight-through`. One run: `git-wrapup` lands the commit stack on `release/<version>`, pushes it, and opens the PR (title = the release commit subject, body = the changelog entry plus a gates section); `release-and-publish` then fast-forwards `main` locally with `git merge --ff-only`, creates the tag on `main`'s tip, pushes `main` and the tag, deletes the branch, and publishes. A caller's brief may run a given release as `gated` instead — a `release-pr-review` pass on the open PR before `release-and-publish`. **Never merge through the GitHub UI or `gh pr merge`**: squash and rebase-merge are disabled in the repo settings because both rewrite the stack (rebase-merge also strips the SSH signatures), and a merge commit breaks the linear history.
329
+
330
+ ---
331
+
305
332
  ## Imports
306
333
 
307
334
  ```ts
@@ -328,7 +355,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
328
355
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
329
356
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
330
357
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
331
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
332
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
333
- - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry with server name key, env vars for any required API keys
358
+ - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name (never the npm scope — `lint:packaging` enforces this); `interface.shortDescription` from `package.json` description
359
+ - [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; every user-supplied variable (API key, contact email, instance URL) is listed in `env_vars` so Codex forwards it from the user's environment. Never write `"KEY": ""` into `env` — an empty value replaces the user's exported key and is read as unset
360
+ - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `author`, `repository`, `license`, `keywords` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name. Every user-supplied variable is declared under `userConfig` (`type`, `title`, `description`; `sensitive: true` for keys and tokens; `required: true` or `default: ""`) and referenced from `env` as `"KEY": "${user_config.<option>}"` — mirror the `user_config` block in `manifest.json`. Never write `"KEY": ""` into `env`
334
361
  - [ ] `npm run devcheck` passes
package/CLAUDE.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** @cyanheads/wsdot-mcp-server
4
- **Version:** 0.2.5
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.12.3`
6
- **Engines:** Bun ≥1.3.0, Node ≥24.0.0
4
+ **Version:** 0.2.6
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.6`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
7
  **MCP SDK:** `@modelcontextprotocol/server` ^2.0.0 (protocol revisions 2026-07-28 and 2025-*)
8
- **Zod:** ^4.4.3
8
+ **Zod:** ^4.6.5
9
9
 
10
10
  > **Read the framework docs first:** `node_modules/@cyanheads/mcp-ts-core/CLAUDE.md` contains the full API reference — builders, Context, error codes, exports, patterns. This file covers server-specific conventions only.
11
11
 
@@ -18,6 +18,7 @@
18
18
  - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
19
19
  - **Need input the caller didn't supply?** `return ctx.requestInput(...)` and read `ctx.inputs` when the handler is re-entered. Never `await` for user input mid-handler.
20
20
  - **Secrets in env vars only** — never hardcoded.
21
+ - **Cut noise.** Add only what earns its place: no speculative generality, no guards for states the framework already prevents (Zod-validated params, classified errors), no abstraction until a third caller proves it, no option nothing sets.
21
22
  - **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed and close it. Do both — a comment without a close leaves stale issues open; a close without a comment leaves no record of what shipped. The comment is for future readers — state the concrete changes, not the conversation that produced them.
22
23
 
23
24
  ---
@@ -83,6 +84,22 @@ export function getServerConfig() {
83
84
 
84
85
  For env booleans use `z.stringbool()`, never `z.coerce.boolean()` — `Boolean("false")` is `true`, so a coerced flag can't be disabled through the environment. `z.stringbool()` parses `true/false/1/0/yes/no/on/off` and rejects anything else, so `=false` actually disables.
85
86
 
87
+ ### Session posture and shutdown
88
+
89
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
90
+
91
+ ```ts
92
+ await createApp({
93
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
94
+ setup(core) { startMyWatcher(core.config); },
95
+ async teardown() { await stopMyWatcher(); },
96
+ });
97
+ ```
98
+
99
+ `sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the option). Add `require: 'stateful'` when a tool asks the caller for input mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused. This server declares `sessionMode: 'stateless'` — no tool calls `ctx.requestInput`.
100
+
101
+ `teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d timer there. It runs after the transport stops and before the logger closes, on every shutdown path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step never settles within the framework's 10 s ceiling). Neither WSDOT service holds one, so no `teardown` is declared.
102
+
86
103
  ---
87
104
 
88
105
  ## Context
@@ -107,7 +124,7 @@ Handlers receive a unified `ctx` object. Key properties:
107
124
 
108
125
  Handlers throw — the framework catches, classifies, and formats.
109
126
 
110
- **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`data.recovery.hint`, mirrored into `content[]` text); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`) bubble freely and don't need declaring.
127
+ **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable?, severity?, thrownBy? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`data.recovery.hint`, mirrored into `content[]` text unless the message already contains it verbatim); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Forwarding it is lint-enforced per throw site (`error-contract-recovery-unforwarded`). Mark an entry the service layer throws with `thrownBy: 'service'` so `error-contract-unthrown` skips it — lint-only metadata, nothing at runtime reads it. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`, `RequestCancelled`) bubble freely and don't need declaring.
111
128
 
112
129
  ```ts
113
130
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -192,9 +209,9 @@ src/
192
209
 
193
210
  ## Skills
194
211
 
195
- Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry.
212
+ Skills are modular instructions in `framework-skills/` at the project root. Read them directly when a task matches — e.g., `framework-skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry. The directory is deliberately not `skills/`: Claude Code and Codex auto-load a plugin's root `skills/`, so a server that ships `.claude-plugin/` or `.codex-plugin/` would hand these development skills to every agent that installs it. Keep `skills/` free for skills meant for those agents.
196
213
 
197
- **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
214
+ **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `framework-skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
198
215
 
199
216
  Available skills:
200
217
 
@@ -213,8 +230,9 @@ Available skills:
213
230
  | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
214
231
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
215
232
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
216
- | `git-wrapup` | Land working-tree changes as a versioned commit + annotated tag — version bump, changelog, verify, tag. Local only. |
217
- | `release-and-publish` | Push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
233
+ | `git-wrapup` | Land working-tree changes as a commit stack — version bump, changelog, verify, commit by concern, release commit on top. No tag, no push to main; opens the release PR when the project declares release PR mode |
234
+ | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixes as ordinary commits on top of the stack, PR body kept in sync. Release PR mode only |
235
+ | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
218
236
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
219
237
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
220
238
  | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
@@ -233,7 +251,7 @@ Available skills:
233
251
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
234
252
  | `api-workers` | Cloudflare Workers runtime |
235
253
 
236
- **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
254
+ **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `framework-skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
237
255
 
238
256
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
239
257
 
@@ -249,7 +267,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
249
267
  | `bun run rebuild` | Clean + build |
250
268
  | `bun run clean` | Remove build artifacts |
251
269
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
252
- | `bun run audit:refresh` | Delete `bun.lock`, reinstall, and re-run `bun audit`. Use when `devcheck` flags a transitive advisory — Bun's `update` is sticky on transitive resolutions, so the advisory may be a stale-lockfile false positive. If it survives the refresh, it's real. |
270
+ | `bun run audit:fix` | `bun audit fix` — upgrade vulnerable packages to the lowest safe version within existing ranges (`--dry-run` previews, `--latest` rewrites ranges). First response when `devcheck` flags a transitive advisory; then `bun update <name>`, then `bun dedupe` |
271
+ | `bun run audit:refresh` | Delete `bun.lock` and reinstall. Last resort after `audit:fix`, `bun update <name>`, and `bun dedupe` — re-resolves every ranged dep (the framework pin included) and rewrites the lockfile as `lockfileVersion: 2` |
253
272
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
254
273
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
255
274
  | `bun run list-skills` | Print the skill registry |
@@ -263,15 +282,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
263
282
  | `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
264
283
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
265
284
 
285
+ **CI is one file.** `.github/workflows/codeql.yml` (scaffolded) is the only GitHub Actions workflow: CodeQL is GitHub-owned end to end, and the file runs only while the repo's CodeQL *default setup* is turned off. Verification — `devcheck`, tests, the release gates — runs locally; don't add a workflow that re-runs it.
286
+
266
287
  ---
267
288
 
268
289
  ## Bundling
269
290
 
270
- `bun run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
291
+ `bun run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
271
292
 
272
- **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match.
293
+ **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match, that every `user_config` option is wired into `mcp_config.env` as `"X": "${user_config.X}"` (the host substitutes nothing else — `"${X}"` reaches the server as that literal string), and that an optional string option carries `"default": ""`.
273
294
 
274
- **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `skills/polish-docs-meta/references/readme.md`.
295
+ **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `framework-skills/polish-docs-meta/references/readme.md`.
275
296
 
276
297
  ---
277
298
 
@@ -296,12 +317,18 @@ security: false # optional — true ONLY for a source
296
317
 
297
318
  `agent-notes` is an optional free-form field for maintenance agents processing the release downstream. Content here won't appear in the rendered CHANGELOG — it's consumed by agents running the `maintenance` skill. Use it for adoption instructions that don't fit the human-facing sections: new files to create, fields to populate, one-time migration steps. Omit entirely when there's nothing to say.
298
319
 
299
- **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security. Include only sections with entries — don't ship empty headers.
320
+ **Section order:** the Keep a Changelog sequence — Added, Changed, Deprecated, Removed, Fixed, Security — then `Dependencies` last. Include only sections with entries — don't ship empty headers.
300
321
 
301
322
  **Tag annotations** render as GitHub Release bodies via `--notes-from-tag`. They must be structured markdown — never a flat comma-separated string. Subject omits the version number (GitHub prepends it). See `changelog/template.md` for the full format reference.
302
323
 
303
324
  ---
304
325
 
326
+ ## Publishing
327
+
328
+ **Every release goes through a release PR, straight-through** — `git-wrapup`'s "Release PR mode", mode `straight-through`. One run: `git-wrapup` lands the commit stack on `release/<version>`, pushes it, and opens the PR (title = the release commit subject, body = the changelog entry plus a gates section); `release-and-publish` then fast-forwards `main` locally with `git merge --ff-only`, creates the tag on `main`'s tip, pushes `main` and the tag, deletes the branch, and publishes. A caller's brief may run a given release as `gated` instead — a `release-pr-review` pass on the open PR before `release-and-publish`. **Never merge through the GitHub UI or `gh pr merge`**: squash and rebase-merge are disabled in the repo settings because both rewrite the stack (rebase-merge also strips the SSH signatures), and a merge commit breaks the linear history.
329
+
330
+ ---
331
+
305
332
  ## Imports
306
333
 
307
334
  ```ts
@@ -328,7 +355,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
328
355
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
329
356
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
330
357
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
331
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
332
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
333
- - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry with server name key, env vars for any required API keys
358
+ - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name (never the npm scope — `lint:packaging` enforces this); `interface.shortDescription` from `package.json` description
359
+ - [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; every user-supplied variable (API key, contact email, instance URL) is listed in `env_vars` so Codex forwards it from the user's environment. Never write `"KEY": ""` into `env` — an empty value replaces the user's exported key and is read as unset
360
+ - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `author`, `repository`, `license`, `keywords` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name. Every user-supplied variable is declared under `userConfig` (`type`, `title`, `description`; `sensitive: true` for keys and tokens; `required: true` or `default: ""`) and referenced from `env` as `"KEY": "${user_config.<option>}"` — mirror the `user_config` block in `manifest.json`. Never write `"KEY": ""` into `env`
334
361
  - [ ] `npm run devcheck` passes
package/README.md CHANGED
@@ -7,7 +7,7 @@
7
7
 
8
8
  <div align="center">
9
9
 
10
- [![Version](https://img.shields.io/badge/Version-0.2.5-blue.svg?style=flat-square)](./CHANGELOG.md) [![License](https://img.shields.io/badge/License-Apache%202.0-orange.svg?style=flat-square)](./LICENSE) [![Docker](https://img.shields.io/badge/Docker-ghcr.io-2496ED?style=flat-square&logo=docker&logoColor=white)](https://github.com/users/cyanheads/packages/container/package/wsdot-mcp-server) [![MCP SDK](https://img.shields.io/badge/MCP%20SDK-^2.0.0-green.svg?style=flat-square)](https://modelcontextprotocol.io/) [![npm](https://img.shields.io/npm/v/@cyanheads/wsdot-mcp-server?style=flat-square&logo=npm&logoColor=white)](https://www.npmjs.com/package/@cyanheads/wsdot-mcp-server) [![TypeScript](https://img.shields.io/badge/TypeScript-^7.0.2-3178C6.svg?style=flat-square)](https://www.typescriptlang.org/) [![Bun](https://img.shields.io/badge/Bun-v1.3.0+-blueviolet.svg?style=flat-square)](https://bun.sh/)
10
+ [![Version](https://img.shields.io/badge/Version-0.2.6-blue.svg?style=flat-square)](./CHANGELOG.md) [![License](https://img.shields.io/badge/License-Apache%202.0-orange.svg?style=flat-square)](./LICENSE) [![Docker](https://img.shields.io/badge/Docker-ghcr.io-2496ED?style=flat-square&logo=docker&logoColor=white)](https://github.com/users/cyanheads/packages/container/package/wsdot-mcp-server) [![MCP SDK](https://img.shields.io/badge/MCP%20SDK-^2.0.0-green.svg?style=flat-square)](https://modelcontextprotocol.io/) [![npm](https://img.shields.io/npm/v/@cyanheads/wsdot-mcp-server?style=flat-square&logo=npm&logoColor=white)](https://www.npmjs.com/package/@cyanheads/wsdot-mcp-server) [![TypeScript](https://img.shields.io/badge/TypeScript-^7.0.2-3178C6.svg?style=flat-square)](https://www.typescriptlang.org/) [![Bun](https://img.shields.io/badge/Bun-v1.4.0%2B-blueviolet.svg?style=flat-square)](https://bun.sh/)
11
11
 
12
12
  </div>
13
13
 
@@ -23,9 +23,11 @@
23
23
 
24
24
  ---
25
25
 
26
- ## Tools
26
+ ## Overview
27
27
 
28
- 12 tools split across two domains — traffic (WSDOT Traveler API) and ferries (WSF Ferry API):
28
+ Washington State transportation data from the WSDOT Traveler API and the WSF Ferry API. Query mountain pass and highway conditions, search alerts and cameras, and track ferry schedules, vessel locations, and terminal space from any MCP client. Runs as a stdio process, a local Streamable HTTP server, or the public hosted endpoint above.
29
+
30
+ ### Tools
29
31
 
30
32
  | Tool | Description |
31
33
  |:---|:---|
@@ -42,112 +44,96 @@
42
44
  | `wsdot_get_terminal_space` | Drive-up and reservable vehicle space available at WSF terminals for upcoming sailings. |
43
45
  | `wsdot_get_ferry_alerts` | Active WSF service disruptions and bulletins with impacted route IDs. |
44
46
 
45
- ### `wsdot_get_mountain_passes`
47
+ ## Capability reference
46
48
 
47
- Current road conditions for all WA mountain passes.
49
+ ### `wsdot_get_mountain_passes` <sub>tool</sub>
48
50
 
49
- - Covers all 16 passes: Snoqualmie, Stevens, White, Blewett, Cayuse, and others
50
- - Fields include status (Open/Closed/Caution), road surface, active traction law, temperature, and elevation
51
- - Use for "is the pass open?", traction law checks, or winter driving planning
51
+ - No input parameters — returns current conditions for all 16 WA mountain passes (Snoqualmie, Stevens, White, Blewett, Cayuse, and others) in one call
52
+ - Fields include road condition, weather, temperature, elevation, and up to two directional traction/travel restrictions
53
+ - Use for "is the pass open?", traction-law checks, or winter driving planning
52
54
 
53
55
  ---
54
56
 
55
- ### `wsdot_search_alerts`
56
-
57
- Active WA highway alerts — incidents, construction, closures, restrictions.
57
+ ### `wsdot_search_alerts` <sub>tool</sub>
58
58
 
59
59
  - Filter by state route — natural forms all work: `"I-90"`, `"90"`, `"090"`, or `"SR 520"` / `"520"`
60
60
  - Filter by WSDOT region: Northwest, Olympic, Southwest, South Central, North Central, Eastern
61
61
  - Filter by milepost range to scope to a corridor — an alert matches when its extent overlaps the range, so a closure that spans the boundary is returned
62
62
  - Omit all filters to return all current statewide alerts
63
- - Descriptions are plain text — upstream authors them with markup, and a link is rendered inline as `link text (url)` so the destination survives
64
- - Results are ordered by `alertId` and paged (default 50, max 500) — pass `offset`/`limit` to page through the full statewide set; the notice reports the next offset. Upstream returns the same alert set in more than one row order, so the ordering is imposed here to keep a given offset reproducible
63
+ - Descriptions are normalized to plain text; a link renders inline as `link text (url)`
64
+ - Results ordered by `alertId` and paged (default 50, max 500) — pass `offset`/`limit`; the notice reports the next offset
65
65
 
66
66
  ---
67
67
 
68
- ### `wsdot_get_travel_times`
69
-
70
- Current vs. average travel times for named WA highway corridors.
68
+ ### `wsdot_get_travel_times` <sub>tool</sub>
71
69
 
72
70
  - Covers I-5, I-90, SR 520, SR 99, I-405, SR 167, and others
73
71
  - Filter by route (`"I-5"`, `"5"`, `"SR 520"`) to get every corridor measured on it, or by any text to match corridor names (`"Everett"`)
74
72
  - When current time exceeds average, the corridor is congested; the delta is the delay
75
73
  - Reversible express-lane corridors report no travel time while closed in the queried direction — those figures are omitted rather than reported as zero minutes
76
- - Results are paged (default 50, max 500) — pass `offset`/`limit` to page through the full statewide set; the notice reports the next offset
74
+ - Results are paged (default 50, max 500) — pass `offset`/`limit`; the notice reports the next offset
77
75
 
78
76
  ---
79
77
 
80
- ### `wsdot_get_toll_rates`
81
-
82
- Current dynamic toll rates for WA tolled facilities.
78
+ ### `wsdot_get_toll_rates` <sub>tool</sub>
83
79
 
84
- - SR 99 (WSDOT Tunnel), SR 167 HOT Lanes, I-405 Express Lanes, the SR 509 tolled segment, and the SR 520 Bridge
80
+ - Covers SR 99 (WSDOT Tunnel), SR 167 HOT Lanes, I-405 Express Lanes, the SR 509 tolled segment, and the SR 520 Bridge
85
81
  - Rates are time-banded and change dynamically based on traffic conditions
86
82
  - `stateRoute` is a bare, zero-padded route number (`"099"`, `"405"`) with no route type; the rendered text resolves the posted designation, so I-405 reads as `I-405` rather than `SR 405`
87
83
  - Each entry leads with its readable `startLocationName → endLocationName` segment; the opaque upstream trip key stays available as `tripName`
88
- - Results are paged (default 50, max 500) — pass `offset`/`limit` to page through the full statewide set; the notice reports the next offset
84
+ - Results are paged (default 50, max 500) — pass `offset`/`limit`; the notice reports the next offset
89
85
 
90
86
  ---
91
87
 
92
- ### `wsdot_get_border_waits`
88
+ ### `wsdot_get_border_waits` <sub>tool</sub>
93
89
 
94
- Current vehicle wait times at WA/Canada land border crossings.
95
-
96
- - Covers I-5 (Peace Arch, Blaine), SR 543 (Pacific Highway, Blaine), SR 539 (Lynden), and SR 9 (Sumas)
90
+ - No input parameters — covers I-5 (Peace Arch, Blaine), SR 543 (Pacific Highway, Blaine), SR 539 (Lynden), and SR 9 (Sumas)
97
91
  - 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
98
92
  - `crossingName` is a route code (e.g. `I5`, `SR543Trucks`); `location.description` holds the readable name
99
93
  - Wait times in minutes; `updateTime` is ISO 8601. A crossing reporting no current data is still returned — only `waitTimeInMinutes` is omitted, and the rendered text reads `Not available`
100
94
 
101
95
  ---
102
96
 
103
- ### `wsdot_search_cameras`
104
-
105
- WSDOT highway camera metadata and image URLs.
97
+ ### `wsdot_search_cameras` <sub>tool</sub>
106
98
 
107
99
  - Filter by state route (`"I-90"`, `"90"`, `"SR 520"`, or `"520"` all work), WSDOT region, or milepost range
108
100
  - Camera road names carry a route-type prefix, so `"SR 26"` excludes US 26 and `"US 97"` excludes US 97A; a bare `"26"` returns both
109
101
  - Returns metadata and image URLs — camera images are copyright WSDOT, not fetched as bytes
110
- - Results are ordered by `cameraId` and paged (default 50, max 500) — pass `offset`/`limit` to page through the full statewide set; the notice reports the next offset. Upstream returns the same camera set in more than one row order, so the ordering is imposed here to keep a given offset reproducible
102
+ - Results are ordered by `cameraId` and paged (default 50, max 500) — pass `offset`/`limit`; the notice reports the next offset
111
103
 
112
104
  ---
113
105
 
114
- ### `wsdot_get_ferry_terminals`
115
-
116
- All WSF ferry terminals with numeric IDs.
106
+ ### `wsdot_get_ferry_terminals` <sub>tool</sub>
117
107
 
118
- - 20 terminals; the list rarely changes
108
+ - No input parameters — returns all 20 WSF ferry terminals; the list rarely changes
119
109
  - Call this first to resolve human-readable names (e.g. "Bainbridge Island", "Seattle", "Kingston") to the numeric IDs required by `wsdot_get_ferry_schedule` and `wsdot_get_terminal_space`
110
+ - Each terminal also carries an abbreviation and coordinates when reported
120
111
 
121
112
  ---
122
113
 
123
- ### `wsdot_get_ferry_routes`
124
-
125
- WSF ferry routes operating on a given date.
114
+ ### `wsdot_get_ferry_routes` <sub>tool</sub>
126
115
 
116
+ - Optional `tripDate` (ISO 8601 `YYYY-MM-DD`); defaults to today
127
117
  - Returns each route's ID, abbreviation, and description
128
118
  - Route IDs correspond to `impactedRouteIds` in `wsdot_get_ferry_alerts` — use this tool to resolve alert route IDs to route names
129
119
  - Use to discover which routes are running; for the numeric terminal IDs that schedule and space lookups need, call `wsdot_get_ferry_terminals`
130
120
 
131
121
  ---
132
122
 
133
- ### `wsdot_get_ferry_schedule`
134
-
135
- Departure times for a specific WSF ferry route.
123
+ ### `wsdot_get_ferry_schedule` <sub>tool</sub>
136
124
 
137
- - Requires numeric terminal IDs — use `wsdot_get_ferry_terminals` first
138
- - `remainingOnly: true` returns only future departures for today (useful for "next ferry" queries)
139
- - For future dates, all sailings for that day are returned
125
+ - Requires numeric `departingTerminalId` and `arrivingTerminalId` — use `wsdot_get_ferry_terminals` first
126
+ - Optional `tripDate` (defaults to today) and `remainingOnly: true` (only future departures for today; ignored for future dates)
140
127
  - `departureTime` and `arrivalTime` are ISO 8601 **UTC**, while `tripDate` is the Pacific service day — an evening sailing therefore carries the following UTC calendar date and will not match `tripDate`. Convert to `America/Los_Angeles` before quoting a clock time
141
128
  - `arrivalTime` is populated on some routes and absent on others
142
129
  - No cancellation status — WSF drops a cancelled sailing from the schedule rather than flagging it, so a listed sailing is not confirmation it will run; check `wsdot_get_ferry_alerts`, which reports disruptions at route level
130
+ - An invalid or non-through terminal pair returns a typed `invalid_terminal_pair` error rather than an empty schedule
143
131
 
144
132
  ---
145
133
 
146
- ### `wsdot_get_vessel_locations`
134
+ ### `wsdot_get_vessel_locations` <sub>tool</sub>
147
135
 
148
- Real-time AIS positions for all active WSF vessels.
149
-
150
- - Fields include position, speed, heading, ETA, and dock status
136
+ - No input parameters — fields include position, speed, heading, ETA, and dock status for every active WSF vessel
151
137
  - Use for "where is the ferry now?" or checking if a specific vessel is in service
152
138
  - Position data may lag 30–60 seconds; many fields are null for vessels not currently operating
153
139
  - Coordinates render at full upstream AIS precision — no rounding, so both response surfaces report the same position
@@ -155,55 +141,60 @@ Real-time AIS positions for all active WSF vessels.
155
141
 
156
142
  ---
157
143
 
158
- ### `wsdot_get_terminal_space`
159
-
160
- Real-time vehicle space availability at WSF terminals for upcoming sailings.
144
+ ### `wsdot_get_terminal_space` <sub>tool</sub>
161
145
 
146
+ - Filter to a specific terminal by ID (from `wsdot_get_ferry_terminals`); omit for all terminals
162
147
  - `driveUpSpaceCount` is the key field — zero means the drive-up lane is full. Oversubscribed sailings report a negative count upstream; it is floored to zero so the value never reads as available space
163
148
  - `arrivingTerminalIds` lists the terminals a sailing serves and chains straight into `wsdot_get_ferry_schedule`; `itineraryLabel` is a display string that may name several stops, not a single destination
164
- - Filter to a specific terminal by ID (from `wsdot_get_ferry_terminals`)
165
- - Use for "will I make the ferry?" or "how full is the next sailing?" queries
166
149
  - 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
167
150
 
168
151
  ---
169
152
 
170
- ### `wsdot_get_ferry_alerts`
171
-
172
- Active WSF ferry service disruptions, delays, and bulletins.
153
+ ### `wsdot_get_ferry_alerts` <sub>tool</sub>
173
154
 
155
+ - No input parameters — active WSF ferry service disruptions, delays, and bulletins
174
156
  - Each alert carries the bulletin's `alertTitle`, its one-line `alertDescription`, and the full `bulletinText` — detail such as a replacement sailing appears only in the body
175
157
  - `bulletinText` is plain text: upstream authors it as HTML, and a link is rendered inline as `link text (url)`
176
158
  - Each alert includes `impactedRouteIds` — cross-reference with `wsdot_get_ferry_routes` to map route IDs to names
177
159
  - `affectsAllRoutes: true` marks a fleet-wide alert, which need not enumerate routes — an empty `impactedRouteIds` then means every route rather than none
178
160
 
179
- ---
180
-
181
161
  ## Features
182
162
 
183
- Built on [`@cyanheads/mcp-ts-core`](https://www.npmjs.com/package/@cyanheads/mcp-ts-core):
184
-
185
- - Declarative tool definitions — single file per tool, framework handles registration and validation
186
- - Unified error handling across all tools
187
- - Pluggable auth (`none`, `jwt`, `oauth`)
188
- - Swappable storage backends: `in-memory`, `filesystem`, `Supabase`, `Cloudflare KV/R2/D1`
189
- - Structured logging with optional OpenTelemetry tracing
190
- - STDIO and Streamable HTTP transports
163
+ Built on [`@cyanheads/mcp-ts-core`](https://github.com/cyanheads/mcp-ts-core): stdio and Streamable HTTP transports, pluggable auth (`none` / `jwt` / `oauth`), swappable storage (`in-memory`, `filesystem`, `Supabase`, `Cloudflare KV/R2/D1`), structured logging with optional OpenTelemetry tracing.
191
164
 
192
165
  WSDOT-specific:
193
166
 
194
- - Dual API integration — WSDOT Traffic API and WSF Ferry API from a single access code
195
- - Retry, timeout, and HTML-detection guards on all upstream requests
196
- - Normalized response shapes across both APIs — sparse upstream fields surfaced as optional rather than omitted
167
+ - Dual API integration — WSDOT Traffic API and WSF Ferry API share a single `WSDOT_ACCESS_CODE`
168
+ - Cross-tool linking built into tool descriptions — ferry tools point to `wsdot_get_ferry_terminals` / `wsdot_get_ferry_routes` for ID resolution before a lookup
169
+ - Normalized response shapes across both APIs — sparse upstream fields surface as optional rather than omitted or defaulted
170
+ - Stable pagination — the alert and camera feeds return the same set in more than one row order upstream, so results are sorted by ID to keep a given offset reproducible
197
171
 
198
172
  Agent-friendly output:
199
173
 
200
- - Cross-tool linking built into descriptions — ferry tools document which tool to call first for terminal and route ID resolution
201
- - `driveUpSpaceCount: 0` and congestion delta fields give agents actionable signal without string parsing
202
- - Partial data preserved — sparse upstream payloads surface `null`/`undefined` rather than synthetic defaults
174
+ - Typed failure — `invalid_access_code` and `api_unavailable` errors carry an explicit recovery hint distinguishing configuration faults from transient upstream ones
175
+ - `driveUpSpaceCount: 0` and congestion delta fields (`delayInMinutes`) give agents actionable signal without string parsing
176
+ - Partial data preserved — sparse upstream payloads surface `null`/`undefined` rather than synthetic defaults (e.g. an omitted `waitTimeInMinutes`, an absent `arrivalTime`)
203
177
  - `content[]` and `structuredContent` carry the same values, not just the same fields — a `false` flag, an empty list, and one populated half of a coordinate pair all render rather than dropping out of the markdown surface that some clients read
204
178
 
205
179
  ## Getting started
206
180
 
181
+ ### Public Hosted Instance
182
+
183
+ A public instance is available at `https://wsdot.caseyjhand.com/mcp` — no installation required. Point any MCP client at it via Streamable HTTP:
184
+
185
+ ```json
186
+ {
187
+ "mcpServers": {
188
+ "wsdot-mcp-server": {
189
+ "type": "streamable-http",
190
+ "url": "https://wsdot.caseyjhand.com/mcp"
191
+ }
192
+ }
193
+ }
194
+ ```
195
+
196
+ ### Self-Hosted / Local
197
+
207
198
  Add the following to your MCP client configuration file. You'll need a WSDOT Traveler API access code — register at [wsdot.wa.gov/Traffic/api/](https://wsdot.wa.gov/Traffic/api/).
208
199
 
209
200
  ```json
@@ -270,7 +261,7 @@ MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 WSDOT_ACCESS_CODE=your-access-code bu
270
261
 
271
262
  ### Prerequisites
272
263
 
273
- - [Bun v1.3.0](https://bun.sh/) or higher (or Node.js v24+).
264
+ - [Bun v1.4.0](https://bun.sh/) or higher (or Node.js v24+).
274
265
  - A WSDOT Traveler API access code. Register at [wsdot.wa.gov/Traffic/api/](https://wsdot.wa.gov/Traffic/api/) — registration is free.
275
266
 
276
267
  ### Installation
@@ -376,7 +367,7 @@ See [`CLAUDE.md`](./CLAUDE.md) for development guidelines and architectural rule
376
367
 
377
368
  ## Contributing
378
369
 
379
- Issues and pull requests are welcome. Run checks and tests before submitting:
370
+ Issues are welcome. Run checks and tests before submitting:
380
371
 
381
372
  ```sh
382
373
  bun run devcheck