Repository navigation
SDK V2 #809
Description
Activity
Does the team plan to migrate to Zod 4 @ihrpr ? (removing passThrough seems to be one step towards that)
Reacted by Inna HarperReacted by lin72hIt would be great if we can include utilizing Typescript's features such as type generics, type inference more to make it a more typescript-native solution and reduce the amount of runtime-only checks.
E.g. PR #859 as a simple example, but there are so many more opportunities.
Is there any place we can find the current status of this work and get a sense for where help is needed and what breaking changes to expect? Preparing for breaking changes is important for my use case.
Reacted by Gareth Andrew, lin72h, Jacob Lauritzen, C. T. Lin and Alexandre DjerbetianSomething that would be nice for v2 is to use the Spec type definitions as they are, and tighten the diff between them and the zod schema-derived types (mostly, dropping passthrough might do the trick).
Took a stab at it in this wip branch (cc/ @felixweinberger )
Reacted by Felix Weinberger and lin72hV2 idea dump (adding to above):
EDIT: Moving to main comment for readability.
Going to keep this as a log of todos for v2:
- SEP-1577 backwards compatibility removal: feat: backwards-compatible createMessage overloads for SEP-1577 #1212
Renaming Server to Session
Class names - make it more like Python SDK (server, session etc)
I mentioned this one to @ihrpr back when this issue was created, but it could use elaboration.
The class we call
Server(andMcpServer) in TS is calledSessionin the Python SDK. The Python naming is more on target. If you look at whatServeractually does, it manages a session for a single client (connected to it via a transport).We create an actual server with Express (or node:http or Hono or whatever) that listens on a port and handles traffic for multiple clients. In order to have an MCP Server that can handle multiple clients, what we have to do is create a new
ServerorMcpServerinstance and connect it to a concreteTransportimplementation.In our actual HTTP server, we map all of the transport/server pairs to their session ids, and when a message comes in, we use the associated transport to handle the message.
The thing that the transport is sending the message to is called a server, but it's really a session handler.
Reacted by Alexandre Djerbetian and Luca Chang- linked a pull request that will close this issue[v2] Мonorepo, `sdk-client`, `sdk-server`, `sdk-core` package split #1279
on Dec 12, 2025 It would be great to get Zod 4 (#555) in here too
While Zod 4 support would be an improvement, I’d argue that decoupling Zod from the SDK altogether is the better long-term architectural choice. It won't stop you from using Zod 4, but would also allow others to use something else.
Currently, the tight coupling forces a specific validation library on all consumers, which creates several downstream issues:
Unnecessary bloat: It imposes a dependency on users who don't use Zod.
Version friction: It causes conflicts for anyone building tools around the SDK or integrating it into existing projects (e.g., vercel/ai#9387, rekog-labs/MCP-Nest#146, and even internal friction).
There has already been successful work done to decouple Zod in this fork: enthspace/mcp-sdk.
That implementation looks like a solid proof-of-concept for how we can keep the core lightweight. We should ideally leave schema validation to "devland," allowing users to plug in their preferred library (Zod, Valibot, ArkType, etc.) rather than baking one in.
Scott
Reacted by Danila Poyarkov, Adam DeHaven, Luca Chang, Alexandre Djerbetian, Konstantin Konstantinov, lin72h, pascal, anuoua, Benedikt Müller and David Phillips- linked a pull request that will close this issue[v2] Decouple `server` from `express` and `hono` - http framework-agnostic MCP server #1326
on Dec 22, 2025 @KKonstantinov @felixweinberger is this really closed? A lot of boxes didn't get checked.
Reacted by pascal and Dmytro TiapukhinDecouple from Zod, allow for any validator ("bring your own").,
When is it planned?
This issue is to track changes we need to have
@KKonstantinov EDITs:
Please note the below is a wishlist, and will be introduced in
v2depending on demand and timeline considerations; Some of it would be opened up for contributors for a PR after thev2refactor./testdirectory/test/helperdirectory - e.g. creating mock server, mock client, connecting them together, etc. etc. (we already have a significant amount we could move there).expressto allow for lighter SDK, and easier compatibility with other HTTP frameworks (e.g.Hono,fastify, others)Bun,Denoon the backend,react-nativeon frontend, etc.)@modelcontextprotocol/typescript-sdk-clientand@modelcontextprotocol/typescript-sdk-serverto reduce package size on users with a single consideration (e.g. either server or client)experimentalfeatures in the SDKonErrorand hook in custom behavior onMcpErrors thrownMcpServer)src/- examples should import from @modelcontextprotocol/sdk to be readily copy-able as opposed to having relative imports in themHeadersas opposed to a custom object in request context