Describe the bug
On @modelcontextprotocol/server-filesystem versions up to and including 2025.8.21, a fresh install resolves zod v4, and the server then advertises every tool with an empty inputSchema — just {"$schema": "http://json-schema.org/draft-07/schema#"}, with no type, no properties, and no required.
Schema conversion appears to fail silently rather than throwing. The server logs Server started and connected successfully and returns a well-formed tools/list response, so nothing looks wrong from the outside — but every tool definition in it is unusable. Strict MCP clients reject the server outright at tools/list.
Forcing zod back to 3.25.76 fixes it completely. Same server version, same Node, same config — the zod version is the only variable.
To Reproduce
Steps to reproduce the behavior:
Install the server on its own:
mkdir /tmp/fsrepro && cd /tmp/fsrepro
npm init -y
npm install @modelcontextprotocol/server-filesystem@2025.8.21
Confirm zod resolved to v4:
node -e "console.log(require('./node_modules/zod/package.json').version)"
Launch the server over stdio:
node node_modules/@modelcontextprotocol/server-filesystem/dist/index.js /tmp
Send initialize, then notifications/initialized, then tools/list.
Inspect any tool's inputSchema in the response.
To confirm the cause, add an overrides block forcing zod to 3.25.76, reinstall, and repeat steps 3–5. The schemas come back correct.
Expected behavior
tools/list should return complete input schemas, as it does when zod v3 is installed:
{
"name": "write_file",
"inputSchema": {
"type": "object",
"properties": {
"path": { "type": "string" },
"content": { "type": "string" }
},
"required": ["path", "content"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}
Failing that, the schema conversion should throw rather than silently returning an empty object, so the incompatibility surfaces immediately instead of appearing as a client-side problem.
Logs
With zod v4 resolved, all 14 tools come back like this:
{
"name": "write_file",
"inputSchema": { "$schema": "http://json-schema.org/draft-07/schema#" }
}
The client rejects the server:
Invalid result for tools/list: [ {
"code": "invalid_value",
"values": ["object"],
"path": ["tools", 0, "inputSchema", "type"],
"message": "Invalid input: expected "object""
}, ... ]
With zod pinned to 3.25.76, probing the same build: 14 tools, all with inputSchema.type == "object", full properties and required. Server loads and every tool works.
Additional context
Verified workaround — npm overrides forcing zod to v3:
{
"dependencies": { "@modelcontextprotocol/server-filesystem": "2025.8.21" },
"overrides": { "zod": "3.25.76" }
}
Likely cause — flagging this as a hypothesis, since I haven't read the conversion code: these releases look like they call a zod v3 API surface while the dependency range permits v4 to resolve, and the mismatch makes conversion return an empty object instead of raising. What I verified directly is only the input/output relationship: zod v4 → empty schemas, zod v3.25.76 → correct schemas, everything else held constant.
Suggested fix — constrain the zod dependency to the major version the code targets, or make schema conversion throw on failure. Either would turn this into an immediate, obvious error.
Why it's worth fixing rather than leaving to version pinning: the failure is silent and misattributed. The resulting client-side error reads like a filesystem permissions or sandbox problem, so users go looking at their own folder configuration. I spent several weeks there before finding this.
Environment
@modelcontextprotocol/server-filesystem 2025.8.21; also reproduced on 2025.7.29 and 2025.8.18
macOS, Darwin 25.6.0
Reproduced both via npx -y and via local npm install
Related, but not this repo's bug: versions from 2025.11.25 onward emit correct input schemas, but declare outputSchema in JSON Schema draft-07, which some clients reject as an unsupported dialect. That's a client-side strictness question and I've reported it to that vendor separately. Worth mentioning only because the combination means there's currently no release of this package that works with such a client — newer releases fail on outputSchema, older ones fail on the empty inputSchema described above.
Describe the bug
On @modelcontextprotocol/server-filesystem versions up to and including 2025.8.21, a fresh install resolves zod v4, and the server then advertises every tool with an empty inputSchema — just {"$schema": "http://json-schema.org/draft-07/schema#"}, with no type, no properties, and no required.
Schema conversion appears to fail silently rather than throwing. The server logs Server started and connected successfully and returns a well-formed tools/list response, so nothing looks wrong from the outside — but every tool definition in it is unusable. Strict MCP clients reject the server outright at tools/list.
Forcing zod back to 3.25.76 fixes it completely. Same server version, same Node, same config — the zod version is the only variable.
To Reproduce
Steps to reproduce the behavior:
Install the server on its own:
mkdir /tmp/fsrepro && cd /tmp/fsrepro
npm init -y
npm install @modelcontextprotocol/server-filesystem@2025.8.21
Confirm zod resolved to v4:
node -e "console.log(require('./node_modules/zod/package.json').version)"
Launch the server over stdio:
node node_modules/@modelcontextprotocol/server-filesystem/dist/index.js /tmp
Send initialize, then notifications/initialized, then tools/list.
Inspect any tool's inputSchema in the response.
To confirm the cause, add an overrides block forcing zod to 3.25.76, reinstall, and repeat steps 3–5. The schemas come back correct.
Expected behavior
tools/list should return complete input schemas, as it does when zod v3 is installed:
{
"name": "write_file",
"inputSchema": {
"type": "object",
"properties": {
"path": { "type": "string" },
"content": { "type": "string" }
},
"required": ["path", "content"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}
Failing that, the schema conversion should throw rather than silently returning an empty object, so the incompatibility surfaces immediately instead of appearing as a client-side problem.
Logs
With zod v4 resolved, all 14 tools come back like this:
{
"name": "write_file",
"inputSchema": { "$schema": "http://json-schema.org/draft-07/schema#" }
}
The client rejects the server:
Invalid result for tools/list: [ {
"code": "invalid_value",
"values": ["object"],
"path": ["tools", 0, "inputSchema", "type"],
"message": "Invalid input: expected "object""
}, ... ]
With zod pinned to 3.25.76, probing the same build: 14 tools, all with inputSchema.type == "object", full properties and required. Server loads and every tool works.
Additional context
Verified workaround — npm overrides forcing zod to v3:
{
"dependencies": { "@modelcontextprotocol/server-filesystem": "2025.8.21" },
"overrides": { "zod": "3.25.76" }
}
Likely cause — flagging this as a hypothesis, since I haven't read the conversion code: these releases look like they call a zod v3 API surface while the dependency range permits v4 to resolve, and the mismatch makes conversion return an empty object instead of raising. What I verified directly is only the input/output relationship: zod v4 → empty schemas, zod v3.25.76 → correct schemas, everything else held constant.
Suggested fix — constrain the zod dependency to the major version the code targets, or make schema conversion throw on failure. Either would turn this into an immediate, obvious error.
Why it's worth fixing rather than leaving to version pinning: the failure is silent and misattributed. The resulting client-side error reads like a filesystem permissions or sandbox problem, so users go looking at their own folder configuration. I spent several weeks there before finding this.
Environment
@modelcontextprotocol/server-filesystem 2025.8.21; also reproduced on 2025.7.29 and 2025.8.18
macOS, Darwin 25.6.0
Reproduced both via npx -y and via local npm install
Related, but not this repo's bug: versions from 2025.11.25 onward emit correct input schemas, but declare outputSchema in JSON Schema draft-07, which some clients reject as an unsupported dialect. That's a client-side strictness question and I've reported it to that vendor separately. Worth mentioning only because the combination means there's currently no release of this package that works with such a client — newer releases fail on outputSchema, older ones fail on the empty inputSchema described above.