build(deps): consolidate Dependabot dependency updates

[bbernstein]

Consolidates the six open Dependabot PRs into a single branch with one consistent package-lock.json, so they can merge together without the sequential merge-and-rebase churn of merging each individually.

Updates included

Source PR	Change	Type
#181	@modelcontextprotocol/sdk ^1.25.1 → ^1.29.0	dependency
#182	zod ^4.3.6 → ^4.4.3	dependency
#183	@graphql-codegen/cli ^6.1.2 → ^7.0.0	devDependency (major)
#184	@graphql-codegen/typescript-operations ^5.1.0 → ^6.0.0	devDependency (major)
#185	eslint ^10.2.1 → ^10.3.0	devDependency
#180	actions/github-script v8 → v9 (release.yml)	CI

Verification (local)

• npm run build (tsc) ✅
• npm run codegen ✅ — the two major graphql-codegen bumps produce no change to existing generated output. Regenerating only surfaced unrelated backend schema additions (auth/multi-tenant types), which are out of scope here, so src/generated/graphql.ts is intentionally left untouched.
• npm run lint (eslint 10.3.0) ✅
• npm test — 653 tests pass ✅

Follow-up

Once this merges, the six source Dependabot PRs (#180–#185) can be closed — Dependabot will detect the dependencies are already at target versions. The recurring red claude-review ❌ on Dependabot PRs is a separate infra issue (Dependabot runs have no access to ANTHROPIC_API_KEY).

🤖 Generated with Claude Code

[claude]

Code Review — PR #186: Consolidate Dependabot dependency updates

Summary: This is a routine dependency-consolidation PR. The changes are confined to package.json, package-lock.json, and .github/workflows/release.yml — no application logic is touched. Overall this is in good shape and the verification steps documented in the description are solid.

---

✅ What looks good

• Batching strategy is sound. Consolidating six sequential Dependabot PRs into one avoids the repeated merge-and-rebase churn and keeps the lock file internally consistent. Good call.
• Verification is thorough. Running build, codegen, lint, and the full 653-test suite locally before opening the PR sets a high bar for confidence.
• Lock file changes look mechanical. The diff is large in line count but it's purely resolved-version and integrity-hash churn — expected for this type of bump.
• actions/github-script v8 → v9 is a minor GHA action bump with no workflow logic changes.
• eslint 10.2.1 → 10.3.0 and zod 4.3.6 → 4.4.3 are both patch/minor bumps with negligible risk.

---

⚠️ Points worth a second look

1. @modelcontextprotocol/sdk 1.25.1 → 1.29.0 (4 minor versions, production dependency)

This is the core SDK this project wraps. Jumping four minor versions at once is fine when tests pass, but it's worth skimming the SDK changelog for any deprecation notices or behavior changes (e.g., tool-call schema validation, streaming semantics). If any new SDK behavior surfaces in production before the next test run, this is the first place to look.

2. @graphql-codegen/cli 6 → 7 and @graphql-codegen/typescript-operations 5 → 6 (both major, dev dependencies)

Major bumps are flagged here not because tests failed — they didn't — but because major versions in codegen tooling sometimes change the shape of plugin config, plugin resolution, or output format in ways that only surface when the schema itself changes. The PR correctly notes that src/generated/graphql.ts is being left as-is because backend schema additions are out of scope. That's the right call for this PR, but it means the first time someone runs npm run codegen after a real schema update will be the true integration test for these tool versions. If the project has a habit of running codegen in CI against a live or stub schema, it might be worth adding that as a follow-up check.

3. No ci.yml changes

The release.yml action was bumped (github-script v8 → v9) but ci.yml wasn't touched. Quick question: does ci.yml also use actions/github-script? If so, it might be worth bumping both to keep versions in sync. (Not a blocker — just worth a check to avoid version drift between the two workflows.)

---

🔒 Security

No concerns. All packages are pinned via the lock file, hashes are updated consistently, and the GHA action bump is to a well-known first-party action. No new network access, permissions, or secret usage is introduced.

---

Verdict

Looks good to merge. The two notes above are informational rather than blocking — the build and test suite passing is the most important signal here. The follow-up cleanup of the six source Dependabot PRs (#180–#185) after merge is well-documented.

🤖 Reviewed with Claude Code

[Copilot]

Pull request overview

This PR consolidates multiple Dependabot updates into a single dependency update set, aiming to produce a consistent package-lock.json and reduce merge churn across dependency bumps and the release workflow.

Changes:

• Bump runtime dependencies: @modelcontextprotocol/sdk to ^1.29.0 and zod to ^4.4.3.
• Bump dev tooling: @graphql-codegen/cli to ^7.0.0, @graphql-codegen/typescript-operations to ^6.0.0, and eslint to ^10.3.0.
• Update release workflow to use actions/github-script@v9.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File	Description
package.json	Updates dependency/devDependency versions to the consolidated set.
package-lock.json	Regenerates lockfile to reflect the consolidated dependency graph and resolved versions.
.github/workflows/release.yml	Bumps actions/github-script from v8 to v9 for the release job.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claude]

Code Review: build(deps): consolidate Dependabot dependency updates

Overall: LGTM — well-structured consolidation with thorough verification. A few notes below.

---

Overview

This PR consolidates 6 open Dependabot PRs into a single branch with a coherent package-lock.json, avoiding the sequential merge-and-rebase churn of landing them individually. The approach is sound and the PR description is exemplary — clear table of changes, documented verification steps, and a sensible follow-up plan.

---

What's Changed

Package	Change	Type
@modelcontextprotocol/sdk	1.25.1 → 1.29.0	runtime dep, 4 minor releases
zod	4.3.6 → 4.4.3	runtime dep, minor
@graphql-codegen/cli	6 → 7	devDep, major
@graphql-codegen/typescript-operations	5 → 6	devDep, major
eslint	10.2.1 → 10.3.0	devDep, patch
actions/github-script	v8 → v9	CI action

---

Positive Observations

• The PR description is excellent: clearly lists each source Dependabot PR, their types, and the exact verification performed.
• Documenting that @graphql-codegen major bumps produce no diff to src/generated/graphql.ts is exactly the right thing to check and report.
• 653 tests passing gives good confidence on the runtime deps (@modelcontextprotocol/sdk, zod).
• Correctly identified that new backend schema types (auth/multi-tenant) surfaced by codegen are out of scope — not silently hiding them.
• The follow-up note about closing PRs ci(deps): bump actions/github-script from 8 to 9 #180–deps(deps-dev): bump eslint from 10.2.1 to 10.3.0 #185 after merging is a good housekeeping detail.

---

Notes / Concerns

1. @modelcontextprotocol/sdk 1.25.1 → 1.29.0 (4 minor releases)

This is the core runtime dependency for the entire MCP server. While tests pass and the TypeScript compiler is happy, minor version bumps in a fast-moving SDK can introduce behavioral changes that unit tests don't exercise (e.g., protocol framing, session lifecycle, tool call serialization). If there's any way to do a quick smoke test with an actual MCP client against the built artifact before merging, that would be ideal. Not a blocker given the test suite coverage, but worth flagging.

2. @graphql-codegen/cli v6 → v7 (major) and typescript-operations v5 → v6 (major)

Both major bumps are dev-only and the "no output change on existing schema" check is the right gate. One mild concern: the note says regenerating surfaces new backend schema additions that are "out of scope here, so src/generated/graphql.ts is intentionally left untouched." This is fine for this PR's scope, but it means the generated types are already drifting from the live backend. A follow-up PR to regenerate and align the types (or a ticket tracking the drift) would be worth creating.

3. actions/github-script v8 → v9

Used in the "Create GitHub Release" step of release.yml. v9 should be backwards-compatible for common use, and the script itself hasn't changed. Low risk.

4. src/generated/graphql.ts not included

As noted above — the intentional omission is correctly explained and scoped. Just make sure a follow-up is tracked somewhere so the type drift doesn't silently accumulate.

---

No Issues Found With

• Lock file structure — additions/deletions look consistent with the version bumps.
• package.json version ranges — all use ^ consistently, matching the existing convention.
• The single-change in release.yml (@v8 → @v9) is minimal and correct.
• No new dependencies introduced, no removed dependencies.

---

Recommendation

Approve and merge. The consolidation approach is the right call. The major version bumps are devDependency-only and have been verified to produce no change in codegen output. Runtime deps are covered by the test suite. The PR description provides enough context for future git log readers to understand what was batched and why.

Reviewed by Claude Code

[claude]

Code Review — PR #186: Consolidate Dependabot dependency updates

Overall: This is a well-structured consolidation PR. The verification checklist (build, codegen, lint, 653 tests) is thorough, and the PR description is clear. A few things are worth flagging before merge.

---

Observations

Node version inconsistency in release.yml

release.yml still pins Node 20 at line 42, while:

• ci.yml tests against Node 22.x and 24.x
• contract-tests.yml was correctly bumped to Node 22 in this PR
• pr-validation.yml and status-checks.yml both use Node 24.x

The release workflow runs npm ci + npm run build against that Node 20 environment. While npm run build (tsc) won't trigger the listr2 engine constraint, this is an inconsistency worth cleaning up. A future step that touches devDeps at runtime on Node 20 (e.g., adding a codegen step to release) would fail unexpectedly.

Suggestion: Bump the node-version on release.yml line 42 to '22' or '24' for consistency.

---

engines field not updated

package.json still declares "node": ">=18.0.0", but @graphql-codegen/cli@7 now pulls listr2, which requires Node >=22.13. A developer on Node 18 or 20 running npm run codegen will get an obscure engine error rather than a useful message.

Suggestion: Update engines to "node": ">=22.0.0" to reflect the actual minimum for the full toolchain, or narrow it to the devDep context with a comment. At minimum, a note in the README would help.

---

@modelcontextprotocol/sdk spans 4 minor versions (1.25.1 → 1.29.0)

This is a runtime dependency. The bump covers 4 minor versions — it would be worth confirming the changelog was reviewed, especially since this is the core protocol library. Minor versions in a pre-1.0-style ecosystem can carry behavioral changes.

---

Major devDep bumps: @graphql-codegen/cli v6→v7 and typescript-operations v5→v6

The PR verifies that re-running codegen produces no output changes to src/generated/graphql.ts, which is the key confirmation here. That's exactly the right check to make. No concerns beyond the engines issue noted above.

---

zod 4.3.6 → 4.4.3 (runtime dep)

Low risk since these are patch/minor versions, but since zod is used in eos-tools.ts for schema validation at the MCP boundary, it's worth a quick check that no validation behavior changed. The passing test suite is a good signal here.

---

Summary

Finding	Severity	Blocking?
release.yml still on Node 20	Low	No — build path doesn't run codegen
engines field not updated to >=22	Medium	No — but will confuse contributors on older Node
MCP SDK changelog review for 1.25.1→1.29.0	Low	No — tests pass
Codegen major bump verification	✅ Done	—

This is safe to merge as-is, but the engines field and release.yml Node version are clean-up items worth addressing either here or in a fast follow.

🤖 Generated with Claude Code