server-gitlab: tools not registered due to zod v3/v4 dependency conflict

[matjoos]

Bug

server-gitlab shows as "Connected" in Claude Code (claude mcp list) but no tools are registered. The tools/list MCP response returns tools with empty inputSchema: {} objects, which causes Claude Code to silently skip them.

Root cause

The npm package has a zod version conflict:

• @modelcontextprotocol/sdk@1.0.1 depends on zod@3.x
• • zod-to-json-schema@3.25.1 resolves zod@4.x at the root
    The server's schemas in schemas.js are created with whatever zod version resolves at the root (v4). But zod-to-json-schema@3.x expects zod v3 schemas. The result: zodToJsonSchema() returns {} for every tool's inputSchema.

To reproduce

npx -y @modelcontextprotocol/server-gitlab
# Server starts, claude mcp list shows "Connected"
# But no tools appear in Claude Code

Verify the conflict:

cd ~/.npm/_npx/<cache-dir>
npm ls zod
# Shows zod@3.x under @modelcontextprotocol/sdk
# Shows zod@4.x under zod-to-json-schema (or at root)

Workaround

Downgrade the root zod in the npx cache:

cd ~/.npm/_npx/<cache-dir>/node_modules/@modelcontextprotocol/server-gitlab/../../..
npm install zod@3.25.76

After this, restart Claude Code and tools appear correctly.

Suggested fix

Pin zod to ^3.x in server-gitlab's package.json dependencies (or update zod-to-json-schema to a version compatible with zod v4).

Related

• connected了，但是没有view-tools #3649 reports the same symptom (connected but no tools)

Environment

• @modelcontextprotocol/server-gitlab@2025.4.25
• • @modelcontextprotocol/sdk@1.0.1
• • • zod@4.3.6 (root) vs zod@3.25.76 (sdk)
• • • • macOS, Claude Code via Desktop app

[raye-deng]

This is a particularly insidious class of dependency failure — the server connects successfully and reports itself as healthy, but silently produces empty schemas that cause downstream tools to be skipped.

We have been tracking these "phantom dependency" patterns in AI-assisted codebases. The zod v3/v4 split is a perfect example: zod@4.x and zod@3.x export types that look structurally identical (both have .parse(), .safeParse(), etc.), so TypeScript compilation succeeds. But zod-to-json-schema does internal instanceof checks that fail silently when the zod instance does not match the expected version — producing {} instead of throwing an error.

This pattern is increasingly common in the MCP ecosystem because:

1. AI coding tools generate package.json entries based on training data that may reference outdated major versions
2. npm resolution hoists the wrong version when multiple packages depend on different zod majors
3. The failure is completely silent — no build error, no runtime exception, just empty objects where schemas should be

The fix for this specific case is straightforward (pin zod or use peerDependencies correctly), but the general class of "two versions of the same package coexist and produce silent behavioral differences" is hard to catch without explicit validation.

We have been building a CI check that detects exactly this: multiple resolved versions of the same package in the dependency tree where the API surface overlaps but the runtime behavior diverges. It catches cases like this before they reach production.