fix(deps): sdk 1.30.0 unblocks @hono/node-server 2.x (closes #49)

[yakimoto]

Closes #49.

@modelcontextprotocol/sdk  1.29.0  → 1.30.0
@hono/node-server          1.19.14 → 2.0.12     (advisory: < 2.0.5, moderate, runtime scope)

#49 asked the wrong question, and the answer changed underneath it

I filed #49 saying this needed a breaking-change assessment because 1.19.14 → 2.0.5 is a major jump. That framing was correct against SDK 1.29.0, which pinned @hono/node-server: ^1.19.9 — the only way through was a pnpm.overrides entry forcing 2.x against a dependency's own declared range, which is exactly the trap in claude-workstation#554.

@modelcontextprotocol/sdk@1.30.0 shipped on 2026-07-27 and widened that range to ^1.19.9 || ^2.0.5. So there is no override, no pin, and no breaking-change assessment to make — the SDK maintainers did it. Updating the SDK is the whole fix.

@hono/node-server is not declared by any manifest in this workspace; it arrives solely through the SDK:

'@modelcontextprotocol/sdk@1.29.0(zod@3.25.76)':
  '@hono/node-server': 1.19.14(hono@4.12.23)

The one manifest line, and why it stays

  "dependencies": {
-   "@modelcontextprotocol/sdk": "^1.0.0",
+   "@modelcontextprotocol/sdk": "^1.30.0",

This is not the churn from claude-workstation#555. That issue is about pnpm update --recursive --lockfile-only silently reformatting all 48 package.json files and unescaping — into literal em-dashes inside published description fields — 928 lines of it, reverted before it could ship. This run touched one manifest and one line.

And it's load-bearing. @wave-av/mcp-server is published, so downstream consumers resolve against its declared range, not our lockfile. Left at ^1.0.0, a consumer could resolve SDK 1.29.x and pull the vulnerable @hono/node-server right back in. ^1.30.0 states the requirement that actually exists.

Verification

CI can't run — Actions are refusing every job org-wide on an account-level billing lock (plan=free, locked=yes, confirmed live this morning against adk and dispatch-edge). All local:

pnpm install --frozen-lockfile   → resolved 188, done      (lock genuinely consistent with manifests)
pnpm -r build                    → success across the workspace
pnpm -r test                     → 143 tests / 52 files / 48 packages, 0 failed
pnpm -r type-check               → no errors

pnpm audit compares version strings and never loads a module, so it can't be the evidence here. Two things stand in for it:

1. Reachability — packages/mcp-server/src/server.ts imports only StdioServerTransport and never constructs an HTTP transport, so @hono/node-server is in the tree but off the exercised code path.
2. The same bump, driven end-to-end on the sibling repo. fix(deps): sdk 1.30.0 unblocks @hono/node-server 2.x, clearing the last two runtime advisories mcp-server#68 has the identical two-package move, and there I spawned the built binary over stdio and completed a real MCP handshake: initialize → wave-mcp-server, protocol 2025-06-18; tools/list → 18 tools, byte-identical to baseline.

Merge-order note

#48 also rewrites sdk-typescript/pnpm-lock.yaml. This PR is based on main @ 9eb128a and is independent of it, but the two will conflict textually. Whichever lands second should re-run its own update command rather than hand-merging the lockfile — a hand-merged pnpm lockfile is how you get a tree that installs but doesn't match either intent.

After #48 and this one, the only alerts left on the repo are vite ×2 and esbuild ×1, all dev-only via vitest, which Renovate #24 already bumps.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}

---

Note

^{Cursor Bugbot is generating a summary for commit 5b956a9. Configure here.}

---

Summary by cubic

Update @modelcontextprotocol/sdk to ^1.30.0 so consumers resolve @hono/node-server 2.x (>=2.0.5) transitively, clearing the advisory without overrides. Added a Security note to the changelog.

• Dependencies
  • @modelcontextprotocol/sdk: 1.29.0 → 1.30.0
  • Transitive @hono/node-server: 1.19.14 → 2.0.12

^{Written for commit 12aff7a. Summary will update on new commits.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 12aff7a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 47 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 115f7791-a196-4253-b288-6be42bcc1c88

📥 Commits

Reviewing files that changed from the base of the PR and between 9eb128a and 12aff7a.

⛔ Files ignored due to path filters (1)

• sdk-typescript/pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (2)

• CHANGELOG.md
• sdk-typescript/packages/mcp-server/package.json

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/mcp-sdk-1.30-hono-node-server

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/mcp-sdk-1.30-hono-node-server

---

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_7383ed78-198a-429f-83ad-92da8f883030)

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​modelcontextprotocol/​sdk@​1.29.0 ⏵ 1.30.0				-4

View full report