Keep MCP tool discovery working across Zod dependency upgrades

[imshashank]

The investigation below traced ctx.deferred.push to two incompatible Zod copies, not an MCP SDK upgrade. Main already pins @modelcontextprotocol/sdk to 1.30.0 and uses Zod 4.4.3; the newer dependency group in #483 still needs a compatible resolution. Earlier groups #432, #434 and #437 are closed, so track the current upgrade here.

Before closing, make the application schemas and SDK JSON Schema conversion use compatible Zod copies, cover a real listTools call with the z.record schemas, and add a dependency check that catches this mismatch. Verify a clean frozen install and the MCP discovery suite. Keep unrelated Better Auth and editor migration failures on #483 separate from this issue.

The root-cause reproduction and the override tradeoff are preserved in the existing comment.

[Chirag6722]

Root cause is a second copy of zod, not the SDK.

The SDK is not moving. @modelcontextprotocol/sdk has been pinned at 1.30.0 in packages/mcp-server/package.json since #167, and bun.lock on main already resolves zod@4.4.3 for it. #437 does not touch the SDK. The only relevant thing it changes is zod 4.4.3 to 4.5.4.

What #437 actually does to zod. Its lockfile has both:

"zod": ["zod@4.5.4", ...]
"@modelcontextprotocol/sdk/zod": ["zod@4.4.3", ...]

So the tool schemas are built with 4.5.4 and the SDK converts them to JSON Schema with 4.4.3. A plain bun install on that branch does not collapse them, I checked.

Standalone reproduction, no Orbit code and no database. In an empty directory:

bun add @modelcontextprotocol/sdk@1.30.0 zod@4.5.4
# then drop a zod 4.4.3 into node_modules/@modelcontextprotocol/sdk/node_modules/zod

Register one tool whose input schema contains z.record(z.string(), z.unknown()), connect a client, call listTools:

record_plain: FAILED -> MCP error -32603: undefined is not an object (evaluating 'ctx.deferred.push')

With a single zod, 4.4.3 or 4.5.4 either way, the same script prints LIST OK.

Why it is the discovery tests and nothing else. ctx.deferred appears in exactly one place in the whole dependency set, zod/v4/core/json-schema-processors.js, in the z.record branch of JSON Schema conversion, and it is initialised only by 4.5's own toJSONSchema entry point. packages/mcp-server/src/tools/org.ts:198 and :234 are the only two z.record schemas we register, and every discovery test lists tools, so every one of them fails. Nothing is wrong with defineTool: it is fine on 4.4.3 and fine on 4.5.4, as long as both sides agree.

Why CI did not catch it. scripts/check-dependency-dedupe.ts only inspects packages named in the root overrides block, and zod is not one of them. This is precisely the single instance hazard CLAUDE.md describes, and the guard for it is opt-in.

Two ways out, and the second is a call for you.

1. Hold zod at 4.4.3 in the patch-and-minor group until the SDK ships a build that resolves 4.5, and let the rest of chore(deps): bump the patch-and-minor group across 1 directory with 44 updates #437 land.
2. Add zod to the root overrides. I tried this on the chore(deps): bump the patch-and-minor group across 1 directory with 44 updates #437 branch: "zod": "4.5.4" collapses it to one copy and removes the nested SDK entry. The catch is that @vercel/cli-config pins zod at exactly 4.1.11, so check-deps then reports zod: @vercel/cli-config asks for '4.1.11' but the root override '4.5.4' installs 4.5.4. No override can satisfy an exact transitive pin and our range at once, so taking this route means deciding what check-deps should do with a third party exact pin it can never satisfy. That is your call rather than mine.

Separately, #437 is already red on check-deps for another reason. Dependabot bumped @codemirror/lang-html to ^6.4.12, @codemirror/state to ^6.7.2 and @codemirror/view to ^6.43.11 in apps/web/package.json but left the root overrides at ^6.4.11, ^6.7.1 and ^6.43.6, so those three bumps are silently swallowed. That is on the branch today, before anything to do with zod.

Happy to open the pull request for whichever of the two you prefer, including the codemirror override bumps.