Skip to content

npm deprecate @modelcontextprotocol/server-filesystem@<=2025.8.21 (empty tool schemas under zod v4) #4702

Description

@olaservo

Follow-up to #4661, which is fixed in the package but not communicated to anyone still pinned to an old version.

What's wrong

Every published server-filesystem up to and including 2025.8.21 calls zodToJsonSchema directly to build its tool schemas. zod-to-json-schema is zod-v3-only, and none of these versions pin zod — it resolves transitively through the SDK. A fresh install today lands on zod 4.x, the conversion silently returns {}, and the server advertises nearly every tool as a bare {"$schema": "http://json-schema.org/draft-07/schema#"}. Strict clients then reject the server at tools/list.

The failure is silent and misattributed — it surfaces client-side as what looks like a permissions or sandbox problem. The reporter on #4661 spent several weeks looking at their own folder configuration before finding it.

Affected versions

All 13 published versions <=2025.8.21. Verified against the published tarballs, not main:

Versions zodToJsonSchema call sites Notes
0.2.0, 0.3.0, 0.5.0 9 don't declare zod-to-json-schema at all; rely on it transitively
0.5.10.6.2 9
2025.1.14, 2025.3.28 11 2025.1.14 reproduced directly: 10/11 tools empty
2025.7.1 12
2025.7.29, 2025.8.18, 2025.8.21 14 2025.8.21 reproduced directly: 13/14 tools empty

list_allowed_directories survives in every case because its schema is a literal object rather than a converted one.

Fixed from 2025.11.25 onward by the registerTool migration, which dropped zodToJsonSchema entirely. 2026.7.10 removed the dependency. Current main has no zod-to-json-schema usage anywhere in src, and no currently published TypeScript server declares it.

Requested action

npm deprecate '@modelcontextprotocol/server-filesystem@<=2025.8.21' \
  'Broken with zod v4: tool input schemas are emitted empty. Upgrade to 2025.11.25 or later.'

Needs someone with publish rights on the @modelcontextprotocol npm scope.

Related but distinct: #4266 asks about deprecating whole stale packages. This one is a version-range deprecation on a package that is actively maintained and whose current release is fine.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions