You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, server.tool() uses a zod3 raw shape type for its input schema. Zod 4 is now currently release, and our input schema validation is all written in zod 4.
There isn't a compatible conversion between zod 3/4 up to now, so we are stuck here.
Describe the solution you'd like
I recommend to use a custom validation schema as an overload for this method, like vercel/ai-sdk.
Describe alternatives you've considered
We would also like to see the method supports v4/v3 both if the type can be inferred.
I've upgraded the library to support Zod V4 and have been using it successfully in my CLI > MCP DXT building library library. If you need compatibility, you can install via NPM registry:
pnpm add @alcyone-labs/modelcontextprotocol-sdk
# or
npm install @alcyone-labs/modelcontextprotocol-sdk
Since it's a re-published package, you will have to import from the NPM package as follows, for example:
The update focuses on upgrading to V4 + getting all tests to pass. Happy to create a PR if needed, but this would potentially break anyone not using V4. I haven't tested it well with V3.
EDIT: I published the package on NPM to make it more deterministic and allow me to keep updating the package from upstream, and have a better sense of whether anyone's using the fork or not (via weekly downloads). The repo is the same, the NPM package is available here: https://www.npmjs.com/package/@alcyone-labs/modelcontextprotocol-sdk
amazing! would be personally fine with a breaking v4 release/pr
Me too. But I think having a V4 branch for a few weeks would make sense, it's going to break many users otherwise, which is undesirable.
Do you think I should publish the version to NPM @wottpal? Hesitant to do so, but would make the code more predictable (I want to upgrade the code from 1.16.0 to 1.17.x but that could break some users code)
EDIT: I did, meaning the import signature will change. Will update previous message.
What you think about gives zod optional? There's many cases where JSONSchema will bet it better.
MCP uses that for validation but it's another abstraction layer where it depends mostly on another library. JSONSchema is more stable and being more specification.
Another case is JSONSchema is more portable, being stuck with zod narrows portability.
Hi! we just shipped a beta release adding backwards compatible support for zod v4 - if you'd like to try it we're keen for feedback to make sure this works well!
Activity
pattobrien commentedon May 31, 2025
Relevant issue: #164
tangye1234 commentedon Jun 17, 2025
I use this type to adopt any json schema library:
#164 (comment)
timonbimon commentedon Jun 23, 2025
We're also blocked by this (all our schema validation is zod 4)
fix: remove zod v4 alias in favour of explicit v4 import
fix: remove zod v4 alias in favour of explicit v4 import
ydennisy commentedon Jul 10, 2025
+1 here
pattobrien commentedon Jul 10, 2025
FWIW, we have full Standard Schema support over at FastMCP; it's a good alternative while this issue is prioritized.
acaumartin-cameleon commentedon Jul 14, 2025
+1
nicolasembleton commentedon Jul 25, 2025
I've upgraded the library to support Zod V4 and have been using it successfully in my CLI > MCP DXT building library library. If you need compatibility, you can install via NPM registry:
pnpm add @alcyone-labs/modelcontextprotocol-sdk # or npm install @alcyone-labs/modelcontextprotocol-sdkSince it's a re-published package, you will have to import from the NPM package as follows, for example:
The repo is available here: https://github.com/Alcyone-Labs/mcp-typescript-sdk
The update focuses on upgrading to V4 + getting all tests to pass. Happy to create a PR if needed, but this would potentially break anyone not using V4. I haven't tested it well with V3.
EDIT: I published the package on NPM to make it more deterministic and allow me to keep updating the package from upstream, and have a better sense of whether anyone's using the fork or not (via weekly downloads). The repo is the same, the NPM package is available here:
https://www.npmjs.com/package/@alcyone-labs/modelcontextprotocol-sdk
wottpal commentedon Jul 29, 2025
amazing! would be personally fine with a breaking v4 release/pr
nicolasembleton commentedon Aug 1, 2025
Me too. But I think having a V4 branch for a few weeks would make sense, it's going to break many users otherwise, which is undesirable.
Do you think I should publish the version to NPM @wottpal? Hesitant to do so, but would make the code more predictable (I want to upgrade the code from 1.16.0 to 1.17.x but that could break some users code)
EDIT: I did, meaning the import signature will change. Will update previous message.
Merge pull request modelcontextprotocol#555 from modelcontextprotocol…
omerfe commentedon Aug 24, 2025
use
import { z } from "zod/v3"on your mcp routes/folders and files until they support v4 and just swap the /v3 with /v4 when they bump itkamsar commentedon Aug 28, 2025
Lots of useful info here on supporting v3 and v4 at the same time: https://zod.dev/library-authors
zdunecki commentedon Sep 25, 2025
What you think about gives zod optional? There's many cases where JSONSchema will bet it better.
MCP uses that for validation but it's another abstraction layer where it depends mostly on another library. JSONSchema is more stable and being more specification.
Another case is JSONSchema is more portable, being stuck with zod narrows portability.
feat: Add Zod 4 support while maintaining Zod 3 compatibility
feat: Add Zod 4 support while maintaining Zod 3 compatibility
felixweinberger commentedon Nov 21, 2025
Hi! we just shipped a beta release adding backwards compatible support for zod v4 - if you'd like to try it we're keen for feedback to make sure this works well!
chore: upgrade @modelcontextprotocol/sdk to 1.22.0 (#20)