MCP SDKのnpmを確認したら、ステートレス仕様の確定日に9パッケージへ分裂していたThe MCP SDK was split into nine separate npm packages coinciding with the…

The Model Context Protocol (MCP) SDK on npm appears to have been reorganized from a single distributable into nine separate packages, a change that a recent blog post reports coincided with the finalization of the protocol's stateless specification. For teams building MCP servers and clients in JavaScript or TypeScript, the split matters in practical terms: it can change import paths, reshape dependency trees, and force adjustments to version pinning, all of which may break builds that assume a monolithic package layout.

MCP is an open protocol, originally introduced by Anthropic, that standardizes how AI applications connect to external tools, data sources, and services. Instead of writing a bespoke integration for every model and every backend, developers expose capabilities through a common interface that any MCP-compatible client can consume. Because the ecosystem is still young and evolving quickly, the SDKs that implement the protocol tend to move in step with specification updates, so structural changes to the published packages are not unusual during periods of rapid iteration.

The reported trigger is the confirmation of the stateless specification. Earlier MCP transports leaned heavily on session-oriented connections, where a server maintained per-client state across a long-lived channel. A stateless mode, generally associated with the Streamable HTTP transport, is designed to let a server answer requests without holding session state between calls. This is significant for modern deployment patterns: serverless functions, containers behind a load balancer, and horizontally scaled fleets all benefit when any instance can service any request without sticky sessions or shared memory. Finalizing that behavior in the spec is the kind of milestone that often prompts a corresponding reorganization of the reference implementation.

Splitting a single SDK into multiple packages is a well-established pattern as a library matures, and the nine-package structure likely reflects a separation of concerns rather than new functionality alone. Although the exact names should be verified directly on npm, such a breakdown commonly isolates core protocol types and schemas, client logic, server logic, and individual transport implementations such as stdio and HTTP-based options into distinct modules. The stated advantages of this approach include better tree-shaking, smaller install footprints for consumers who need only part of the toolkit, clearer versioning of independent components, and the ability to iterate on one piece without forcing a release of everything else. The trade-off is added coordination: consumers must now track several version numbers and ensure that the packages they combine are mutually compatible.

For developers, the immediate task is to audit dependencies and confirm which packages their projects actually require. Codebases that imported everything from one entry point will probably need to update their import statements and package manifests, and lockfiles should be regenerated to capture the new graph. It is prudent to check release notes or changelogs for any breaking changes tied to the stateless work, since transport-level adjustments can affect how servers are initialized and how they respond to clients. Where possible, aligning on matching versions across the split packages reduces the risk of subtle runtime mismatches.

This move fits a broader industry trend toward modular SDKs managed within monorepos and published as coordinated package sets, an approach visible across many large JavaScript projects. It also mirrors the general direction of the MCP ecosystem, which spans SDKs in several languages, a growing catalog of community and vendor-built servers, and integrations in AI development tools and assistants. As more of those integrations depend on the stateless transport for scalable hosting, a cleaner package boundary between protocol, transport, and application logic is a reasonable step, though it does raise the bar for keeping documentation and examples current.

Readers should treat the specific figure of nine packages and the exact timing as a snapshot from a single blog observation rather than a formal announcement, and confirm the current state on the official npm registry and the protocol's own documentation. The underlying takeaway is durable regardless of the precise count: MCP's tooling is consolidating around a stateless-friendly design, and developers who depend on the SDK should expect to revisit their dependency configuration and test their servers against the finalized specification before upgrading in production.