The official SDK covers both sides of MCP v2
The TypeScript SDK is the reference choice when a JavaScript application needs to speak MCP rather than merely call one MCP server. Its split v2 packages cover servers, clients, tools, resources, prompts, stdio, Streamable HTTP, and OAuth helpers. Optional adapters connect the HTTP transport to Express, Fastify, Hono, or Node.js itself. The SDK runs on Node.js, Bun, and Deno, which gives TypeScript teams a shared protocol layer without forcing every deployment onto the same runtime.
Main now implements the 2026-07-28 MCP specification, and the README calls v2 the stable line. Existing v1 users have a separate v1.x branch and documentation site, with bug fixes and security updates promised for at least 6 months after v2's release. That split is sensible, but it makes version selection the first design decision. Mixing a v1 tutorial, a v2 import, and a client pinned to another protocol revision is an avoidable way to lose an afternoon.
Two packages replace the old single-package assumption
Version 2 publishes @modelcontextprotocol/server and @modelcontextprotocol/client separately. A server can register a typed tool and connect it to stdio with a small amount of code. A client gets transports, higher-level helpers, and OAuth support without pulling in server behavior. Tool and prompt schemas follow Standard Schema, so Zod v4, Valibot, ArkType, and compatible validators can sit at the boundary.
The middleware packages are deliberately narrow. Four documented adapters handle Node.js HTTP, Express, Fastify, and Hono while leaving protocol behavior in the main server package. That keeps framework integration replaceable and lets an existing web application host MCP beside its other routes. It also means the install command in a tutorial is only the beginning: an HTTP service still needs host validation, authentication decisions, request limits, deployment health checks, and tests against the actual client that will call it.
What happened when we ran it
Our sandbox installed commit 3924de9 in 33 seconds. Pnpm added 877 packages and the resulting dependency tree occupied 665 MB. The source checkout itself contained 1,121 files, about 186,337 lines of source, and 10.2 MB before dependencies. That is a substantial workspace for a protocol SDK, although consumers install one or two published packages rather than cloning the whole development tree.
The root exposed no build script or target, so we skipped the build. It also exposed no test script or target, so we skipped tests. Those are neutral descriptions of what the checkout allowed, not successful results. Our scan did find a tests directory and 8 CI workflow files, which suggests verification exists in more specific workspace commands. A contributor must identify those commands before using a green local run as evidence that a change is safe.
The run used an unprivileged Node 22 Debian container with 3 CPUs, 8 GB of RAM, and no secrets. We did not launch an MCP client-server pair, configure OAuth, or judge transport compatibility. The measured result says dependency installation worked and consumed 665 MB. It says nothing about latency, throughput, or whether a particular host application implements the same protocol revision.
Active schema and negotiation bugs deserve regression tests
Issue 2721 reports that an SDK v1 server emits tool output schemas as JSON Schema draft-07 when no target is supplied. The reporter says strict clients accepting only JSON Schema 2020-12 then reject the schema. This is exactly the sort of boundary disagreement MCP is meant to reduce, and it is a reason to test tools/list output with the clients you support rather than trusting that a valid TypeScript type guarantees wire compatibility.
A separate v2 report, issue 2722, says a pinned 2026-07-28 client can misclassify a conforming server response during version negotiation when discovery fields appear at the documented top level. Both reports were active on August 26, 2026. Neither proves the SDK is broadly unreliable. They do show that fast-moving specification work reaches ordinary integration points such as schema dialects and handshake parsing. Pin package versions and keep a small cross-client test fixture in CI.
OAuth support is useful, and security work is still moving
The client package includes OAuth helpers, while server packages expose authentication building blocks for remote deployments. Current issue activity includes Azure refresh-token scope handling and a proposed redirect check intended to block public endpoints from forwarding clients toward loopback, private network, or cloud metadata addresses. Those are concrete reminders that a remote MCP transport crosses a security boundary. Tool descriptions may look harmless while the transport can hold tokens and reach privileged services.
The official status helps here because protocol changes, conformance work, and security fixes land near the specification. It also creates churn. GitHub showed 585 open issues and pull requests combined, 13,252 stars, and a last push on August 26, 2026. The queue is too mixed to read as 585 defects, but the same-day activity and detailed reproductions show a project under heavy development rather than a quiet compatibility layer.
Documentation is strongest when you stay inside one generation
The README links separate 10-minute server and client tutorials, runnable paired examples, troubleshooting, migration guides, and generated API references. It also documents how to build a combined v1 and v2 site. This is better than forcing users to infer transport setup from type declarations. The catch is navigational: search results and old examples can still lead to v1 shapes, while the main branch teaches v2. Check the URL and package name before borrowing code.
For a new TypeScript MCP product, this SDK should be the baseline comparison. Our 33-second install makes a trial cheap enough, but the missing root verification targets mean contributors need to learn the monorepo rather than stop after pnpm install. Teams shipping remote servers should add their own negotiation, schema, cancellation, and OAuth regression cases. Teams building only a small server may prefer FastMCP's higher-level API, while anyone implementing both client and server behavior will get more direct value from the official split packages.