chore: bump @modelcontextprotocol/sdk from 1.29.0 to 1.30.0 - #29
Conversation
dependabot
Bot
added
dependencies
aff505c to
a30ae39
Compare
|
Claude finished @dependabot[bot]'s task in 2m 53s —— View job Dependency review:
|
| Change | Relevant here? |
|---|---|
| Validate Content-Type by parsed media type (#2444) | No — Streamable HTTP server transport only |
| SSE keep-alive frames + timer lifecycle (#2538, #2547) | No — Streamable HTTP only |
@hono/node-server widening (#2549) |
Not at runtime — see §3 |
| v1 stdio buffer limit (#2239) | Yes — this is the transport this repo uses |
fix(server): prioritize zod issues and format them (#1503) |
Yes, cosmetically — changes tool-input validation error text |
More than half the release is Streamable-HTTP work that this server never loads, which is why the risk here is low.
The stdio buffer limit is the one change that lands on a code path this repo actually runs. It caps the inbound read buffer on StdioServerTransport (src/index.ts:103). Inbound traffic here is small (tool calls carrying a query string or a params object), and a read-buffer cap should not constrain the large JSON responses this server writes outbound — execute_read_action results can be sizeable even after pickFields. I could not read the SDK source to confirm the cap's default value or that it is inbound-only, so I'd treat that as an assumption rather than a verified fact. Cheap to confirm once merged: run a real execute_read_action against a broad endpoint with no fields filter and check the response arrives intact.
Validation error formatting (#1503) changes the message shape when an LLM passes a bad actionId/params/fields to a tool. Nothing asserts that text, so this is purely a change in what the model reads back. No action.
3. The @hono/node-server advisory — previous review's point still stands
The widening in #2549 was specifically to escape GHSA-frvp-7c67-39w9, but the lockfile still resolves @hono/node-server to 1.19.13 (package-lock.json:470). Dependabot updated the SDK entry without re-resolving an already-locked transitive dep that still satisfies the new range, so the ^2.0.5 branch is not taken — the tree is byte-identical to before on that package.
Two honest caveats on my end: npm/gh api and the web tools were not permitted in this run, so I could not run npm audit or read the advisory to confirm whether 1.19.13 is in the affected range. If the advisory has a 1.x patch at or below 1.19.13, this is a non-issue and the widening is just the SDK opening the door to hono v2.
What I can say with confidence: this is not reachable at runtime here — the server only ever constructs StdioServerTransport, so hono and the Streamable HTTP path are never imported. But it is a published runtime dependency of @kosli/mcp-server, so it will surface in consumers' npm audit regardless of reachability. If audit does flag it:
"overrides": { "@hono/node-server": "^2.0.5" }4. Pre-existing: zod is a phantom dependency
Not introduced by this PR, but this bump is exactly what governs it, so it's worth surfacing here. src/index.ts:4 imports zod directly, and zod is not in package.json dependencies — it resolves only because the SDK depends on it (^3.25 || ^4.0, currently hoisted to 4.3.6).
That range spans a major, and this release's fix: support Zod 3.25 method literals (#2368) confirms the SDK is actively maintaining both majors. So which zod lands in a consumer's tree is decided by the SDK and by whatever else is installed alongside it — nothing in this repo's manifest pins it. A consumer with zod 3 elsewhere could hoist v3 under npx @kosli/mcp-server, and any v4-only surface in the tool schemas would break at runtime, not at build time. Declaring it explicitly costs one line and removes the whole class of problem:
"dependencies": {
"@modelcontextprotocol/sdk": "^1.29.0",
"zod": "^4.0.0"
}Worth its own PR against main rather than piggybacking on a Dependabot branch.
5. Verification status
CI passed on the recreated branch (run 31702525330) — build, tests, and the .mcpb pack smoke test, on both Node 22 and 24. That covers the tsc check of registerTool against the new type definitions, which is the most likely place a breaking SDK change would show up.
I could not reproduce it locally: node_modules is absent on this checkout and npm ci was not an approved command in this session, so the build, test suite, and npm audit are CI's word rather than mine here.
One gap that colours how much green CI proves: nothing under test/ imports the SDK (the suite covers the catalog, client, search, and scripts), and CI never launches the server. So the runtime handshake — registerTool actually registering, annotations reaching the client, stdio framing — is unexercised in both. A type-clean SDK regression would ship undetected. A small startup smoke test would close that, and would have made this review conclusive rather than mostly-static:
Summary of what I did: reviewed the diff, checked semver and the Node floor, triaged all ten changelog entries against the two SDK import sites, re-examined the @hono/node-server finding from the earlier review, and read CI's result. Not done: local build/test/npm audit (no node_modules, npm not permitted here) and direct confirmation of the advisory's affected range (web tools not permitted). No files changed.
· branch dependabot/npm_and_yarn/modelcontextprotocol/sdk-1.30.0
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| "license": "MIT", | ||
| "dependencies": { | ||
| "@hono/node-server": "^1.19.9", | ||
| "@hono/node-server": "^1.19.9 || ^2.0.5", |
There was a problem hiding this comment.
The SDK widened this range specifically to get past GHSA-frvp-7c67-39w9, but the lockfile still resolves @hono/node-server to 1.19.13 (line 470) — the widened ^2.0.5 branch is not taken, so if the advisory covers 1.x this bump does not actually pick up the fix.
Not reachable at runtime here (this server only uses StdioServerTransport, so the hono/Streamable-HTTP path is never loaded), but it will still show up in npm audit and in the published dependency tree. Worth running npm audit on this branch and, if 1.19.13 is flagged, adding an override:
"overrides": { "@hono/node-server": "^2.0.5" }
a30ae39 to
22f897d
Compare
|
@dependabot rebase |
|
Looks like this PR is already up-to-date with main! If you'd still like to recreate it from scratch, overwriting any edits, you can request |
|
@dependabot recreate |
Bumps [@modelcontextprotocol/sdk](https://github.com/modelcontextprotocol/typescript-sdk) from 1.29.0 to 1.30.0. - [Release notes](https://github.com/modelcontextprotocol/typescript-sdk/releases) - [Commits](modelcontextprotocol/typescript-sdk@v1.29.0...1.30.0) --- updated-dependencies: - dependency-name: "@modelcontextprotocol/sdk" dependency-version: 1.30.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
22f897d to
d6620d3
Compare
1 participant
Bumps @modelcontextprotocol/sdk from 1.29.0 to 1.30.0.
Release notes
Sourced from @modelcontextprotocol/sdk's releases.
Commits
2d889f2chore: bump version to 1.30.0 (#2563)e3f3daaFix SSE keep-alive timer lifecycle in Streamable HTTP server transport (v1.x)...bb5a718fix(deps): widen@hono/node-serverpast GHSA-frvp-7c67-39w9 (#2549)1dad263fix: send SSE keep-alive comment frames from Streamable HTTP server transport...69749aaValidate Content-Type by parsed media type instead of substring match (v1.x) ...369513dfix: support Zod 3.25 method literals (#2368)e7ee57cv1 stdio buffer limit (#2239)c36e1efAdd end-to-end test suite (#2167)bf1e022chore(ci): switch publish to OIDC trusted publishing (#1839)9edbab7fix(server): prioritize zod issues and format them (#1503)Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for
@modelcontextprotocol/sdksince your current version.