server-filesystem ≤2025.8.21 emits empty inputSchema when zod v4 is resolved #4661

Activity

1. pauxier-coder

   added

   bugSomething isn't workingSomething isn't working

   on Aug 17, 2026
2. ramiiZPD commented on Aug 21, 2026

   

   ramiiZPD

   on Aug 21, 2026

   Last edited by ramiiZPD

   More actions

   Thanks for the detailed writeup, the repro steps made this easy to check. I pulled current main (599dafc1), installed src/filesystem fresh with no overrides, and it resolved the same zod major you flagged ([email protected] alongside @modelcontextprotocol/[email protected]). Built it, ran it over stdio, and walked through initialize → notifications/initialized → tools/list by hand.

   Couldn't reproduce it, though. All 14 tools came back with full schemas. write_file looked like this:

   {
     "$schema": "http://json-schema.org/draft-07/schema#",
     "type": "object",
     "properties": {
       "path": { "type": "string" },
       "content": { "type": "string" }
     },
     "required": ["path", "content"]
   }

   Dug a bit further to see why, since your hypothesis about the conversion made sense to me. Turns out @modelcontextprotocol/[email protected] already has a fix for this: server/zod-json-schema-compat.js checks for zod v4 (schema._zod) and hands those schemas to zod/v4-mini's own toJSONSchema() instead of the old zod-to-json-schema package, which really is still v3-only under the hood. That compat file evidently didn't exist yet in the SDK version bundled with the server-filesystem release you tested (2025.7.29 through 2025.8.21), so this was a real bug, it's just been fixed one layer up since then.

   Since servers itself never does the schema conversion (it just hands .shape to registerTool), there's nothing to patch here. It's inherited automatically once the SDK dependency is current. Probably safe to close, unless there's a still-published server-filesystem build out there pinned to an older SDK that would still hit this.
3. pauxier-coder commented on Aug 21, 2026

   

   pauxier-coder

   on Aug 21, 2026

   Author

   More actions

   Thanks for running it. That's more than I expected.

   I think we tested two different things. You built main. My report is about the published tarballs on npm, which is what npx -y @modelcontextprotocol/[email protected] actually runs, and that's different code.

   I re-ran it today against the published 2025.8.21. Fresh install, no overrides:

   @modelcontextprotocol/[email protected]
   +-- @modelcontextprotocol/[email protected]
   | +-- [email protected] deduped
   | -- [email protected] -- [email protected]
   Same SDK 1.30.0 and the same zod 4.4.3 you had. Still broken. Walking initialize → notifications/initialized → tools/list gives 14 tools, and 13 of them come back as just this:

   { "$schema": "http://json-schema.org/draft-07/schema#" }
   The one that survives is list_allowed_directories, and only because its schema is written out as a literal object in the source instead of being converted.

   Here's why the SDK compat file doesn't help. Published 2025.8.21 never calls registerTool. It registers a raw handler and builds every schema itself:

   dist/index.js:9 import { zodToJsonSchema } from "zod-to-json-schema";
   dist/index.js:134 server.setRequestHandler(ListToolsRequestSchema, async () => {
   dist/index.js:173 inputSchema: zodToJsonSchema(WriteFileArgsSchema),
   zod-to-json-schema is a direct dependency of the package at that version. The conversion happens before the SDK sees anything, so server/zod-json-schema-compat.js never runs. And the package declares @modelcontextprotocol/sdk: ^1.17.0, so a fresh install already pulls 1.30.0. A current SDK doesn't rescue it.

   What did fix it is the move to registerTool. Published 2025.11.25 and 2026.7.10 both use it, and neither imports zod-to-json-schema at all, which matches those versions emitting correct input schemas in my original table. main picks up the SDK fix for the same reason.

   So I'm fine with closing this. The bug is real but bounded: published versions ≤2025.8.21 only, no SDK upgrade clears it, and from a user's side the only fixes are moving to 2025.11.25 or later, or pinning zod to 3.25.76.
4. banks0frome commented on Aug 27, 2026

   

   banks0frome

   on Aug 27, 2026

   More actions

   I built and independently verified a bounded proof for this issue.

   The independently accepted artifact contains this standalone checker for maintainer review:

   import fs from 'node:fs';
   const path = process.argv[2];
   if (!path) {
     console.error('schema-lock: usage: node check-mcp-schema.mjs <tools-list.json>');
     process.exit(2);
   }
   let payload;
   try { payload = JSON.parse(fs.readFileSync(path, 'utf8')); }
   catch (error) {
     console.error(`schema-lock: cannot read payload: ${error.message}`);
     process.exit(2);
   }
   if (payload?.jsonrpc !== '2.0' || !payload?.result || !Array.isArray(payload.result.tools)) {
     console.error('schema-lock: invalid tools/list JSON-RPC response; expected result.tools array');
     process.exit(2);
   }
   const tools = payload.result.tools;
   if (tools.length === 0) {
     console.error('schema-lock: no tools captured; verify the adapter and server fixture');
     process.exit(2);
   }
   const invalid = tools.filter(tool => {
     const s = tool?.inputSchema;
     return !s || typeof s !== 'object' || Array.isArray(s) ||
       s.type !== 'object' || !s.properties ||
       Object.keys(s).every(k => k === '$schema');
   });
   if (invalid.length) {
     console.error(`schema-lock: ${invalid.length}/${tools.length} invalid tool schemas`);
     process.exit(1);
   }
   console.log(`schema-lock: ${tools.length} valid tool schemas`);
   

   This inline artifact is the product test; it is not evidence of maintainer adoption.

   If this is useful, I’ll wait for maintainer direction on this issue before opening a PR.
5. olaservo commented on Aug 27, 2026

   

   olaservo

   on Aug 27, 2026

   Member

   More actions

   Confirmed, and fixed from 2025.11.25 onward.

   Reproduced your report exactly against the published tarball. A fresh npm install @modelcontextprotocol/[email protected] resolves zod 4.4.3 and SDK 1.30.0, and tools/list returns 13 of 14 tools as bare {"$schema": "http://json-schema.org/draft-07/schema#"}. list_allowed_directories survives because its schema is a literal object in the source rather than a converted one. The control on 2026.7.10, same zod 4.4.3, returns full schemas for all 14.

   Version	zodToJsonSchema call sites	zod-to-json-schema dep	Result under zod 4.4.3
   2025.8.21	14	^3.23.5 direct	13/14 tools empty
   2025.11.25	0	declared, unused	correct
   2026.7.10	0	removed	correct

   @pauxier-coder is right that a current SDK does not rescue 2025.8.21. That version calls zodToJsonSchema itself at dist/index.js:173 and declares zod-to-json-schema as its own direct dependency, so the conversion completes before the SDK sees the schema and server/zod-json-schema-compat.js never runs. @ramiiZPD's run was against main, which uses registerTool and was never affected.

   Nothing left to patch: main has no zod-to-json-schema usage in src, and none of the currently published TypeScript servers declare it. Fixes are to move to 2025.11.25 or later, or pin zod to 3.25.76 if you must stay on the older release.

   Agreed the silent failure was the worst part of this. Thanks for the repro steps!
6. olaservo

   closed this as completedon Aug 27, 2026
7. dodogeny commented on Sep 1, 2026

   

   dodogeny

   on Sep 1, 2026

   More actions

   This is a brutal one to debug — “surfaces client-side as what looks like a permissions or sandbox problem” is exactly why it took someone weeks to trace back to the server. Nothing about the symptom points at the real cause.

   We build Apitella, which diffs a server’s tools/resources/prompts across releases — this is close to the canonical case for it: 13 of 14 schemas silently collapsing to {} would show up as a breaking-change alert the moment that release went out, not weeks later downstream. Mentioning it mainly because the mechanism here is such a clean illustration, not trying to sell you on anything — you clearly know this problem better than most.