V2 splits the official SDK into focused packages
The stable v2 line no longer asks every TypeScript application to depend on one catch-all SDK package. @modelcontextprotocol/server handles tools, resources, prompts, transports, and server auth helpers. @modelcontextprotocol/client contains client transports, higher-level calls, and OAuth support. That split makes dependencies clearer for applications that live on only one side of the protocol.
The main branch implements the 2026-07-28 MCP specification. Server and client packages were both at version 2.1.0 when checked. Tool and prompt inputs use Standard Schema, so a project can choose Zod v4, Valibot, ArkType, or another compatible validator.
Node 20 is the floor, with Bun and Deno also supported
The current core, server, and client package manifests require Node.js 20 or newer. For HTTP servers, separate adapters cover Express, Fastify, Hono, and Node's native request and response objects. Stdio remains the short route for local desktop integrations, while Streamable HTTP fits remote or shared services.
A minimal server can register one typed tool and connect it to stdio in a small file. A production server has more decisions than that example shows: origin and host checks, authentication, request limits, cancellation, logging, and a policy for tool errors. The 2.1.0 middleware packages are intentionally thin, so they do not own those application choices. That is appropriate for an SDK, but it rules out a copy-and-deploy reading of the quick start.
What happened when we ran it
Our sandbox installed 877 pnpm packages in 25 seconds and used 665 MB on disk. The checkout itself was 10.5 MB, with 1,131 files and roughly 191,127 source lines. Installation completed successfully in an unprivileged Node 22 Debian container with 3 CPUs, 8 GB of RAM, and no secrets.
The harness found no default root build script or target, so it skipped the build. It found no default root test script or target, so it skipped tests as well. The repository does have workspace commands named build:all and test:all, plus 8 CI workflow files and a tests directory. We did not run those alternate commands, which means this result proves dependency installation only. It contains no passing compiler or test evidence.
The missing default targets matter mainly to contributors. An application consuming @modelcontextprotocol/server does not install this entire 665 MB development workspace. Anyone changing the SDK itself should follow its named monorepo commands and CI matrix rather than relying on a generic package harness.
V1 and v2 need separate upgrade plans
The README keeps v1 source and fixes on the v1.x branch, with a separate documentation site. It promises bug fixes and security updates for at least 6 months after v2's release. New projects should start with the split v2 packages. Existing users should read the migration material before changing imports because package names, middleware placement, and some extension points differ.
Search results can still land on a v1 example while the main branch teaches v2. Check the documentation URL, import path, package version, and MCP specification date together before copying code. The repository's recent releases include both the v1 line at 1.30.1 and several v2 packages at 2.1.0. Those numbers describe different generations, so a lockfile is more useful than a vague requirement for the latest SDK.
The Node adapter has an open Hono peer trap
Open issue 2882 reports that @modelcontextprotocol/node marks Hono as optional while its @hono/node-server dependency requires Hono. With strict peer checking, pnpm can stop at install time. The report also says a future resolution to @hono/node-server 2.x can turn the mismatch into an import failure because that package loads hono/ws. The monorepo can miss the consumer failure because another workspace package already supplies Hono.
This is a focused issue, not a reason to reject all 4 middleware adapters. It is a reason to test the exact package set from an empty application with the same peer-dependency rules used in production. Node HTTP users can also evaluate whether the native adapter is necessary for their route or whether Express, Fastify, or Hono already owns that boundary. Pinning 2.1.0 alone does not replace the clean-project test described in the issue.
OAuth behavior needs real provider fixtures
The client includes discovery, registration, redirect, and token helpers, but providers still differ at the edges. Open issue 2784 reports a fallback metadata URL being built from the resource host instead of the authorization server host when the two differ. In the supplied reproduction, that sends the client toward metadata for an unrelated service. The measured commit itself fixed a separate case involving *.localhost OAuth token endpoints.
A useful auth suite should cover at least one provider on another host, refresh behavior, rejected redirects, and the exact callback URL used after deployment. Our 25-second install cannot answer any of those questions. Nor does a successful local stdio example exercise remote authorization. The SDK gives you protocol machinery; your provider fixtures prove that the machinery and your identity system agree.
Same-day maintenance comes with a large review queue
GitHub showed a push on September 28, 2026, the same day as active issue and pull request updates. The repository had 13,479 stars and 654 combined issues and pull requests. That combined count is not a bug count. It does show how much specification, transport, packaging, and compatibility work flows through the official TypeScript implementation.
For new TypeScript MCP software, this SDK is the baseline choice. The split 2.1.0 packages cover both sides of the protocol and keep framework adapters optional. Budget extra care for version selection, consumer-level package tests, and OAuth fixtures. If your team works mainly in Python, Go, or C#, the official SDK in that language will usually produce a simpler service than carrying a separate JavaScript runtime just for MCP.