Finding. Nine widely-used MCP clients were checked for the Model Context Protocol SDK version they pin. No two are on the same footing, versions span 1.24.0 to 1.30.0, and four of the six distinct TypeScript versions pinned have no corresponding tag in the SDK’s own repository. One project pins two different SDK versions in the same repo.
The practical consequence is narrow and awkward: for most of these clients you cannot check out the source of the SDK version they depend on.
What each client pins
| Client | Stars | Manifest | Pinned | Tag in SDK repo |
|---|---|---|---|---|
| lobehub | 82,236 | package.json | ^1.30.0 | absent |
| Cline | 67,468 | apps/vscode/package.json | 1.25.1 | absent |
| AnythingLLM | 65,610 | server/package.json | 1.24.3 | absent |
| Goose | 53,906 | Cargo.toml | rmcp 3.0.0 | n/a — Rust SDK |
| Cherry Studio | 51,430 | package.json | 1.27.1 | present |
| LibreChat | 42,812 | api/package.json | 1.30.0 | absent |
| AstrBot | 40,011 | pyproject.toml | mcp>=1.8.0,<2 | floor, not a pin |
| Continue (core) | 35,757 | core/package.json | 1.25.2 | present |
| Continue (cli) | 35,757 | extensions/cli/package.json | 1.24.0 | absent |
| LangBot | 17,654 | pyproject.toml | mcp>=1.25.0,<2 | floor, not a pin |
Continue is the case worth pausing on. Its editor extension and its command-line tool pin different SDK versions in the same repository, so the same product can negotiate a different protocol depending on which surface a user reaches for. Nothing about that is visible to the user.
The two Python clients pin a floor rather than a version. mcp>=1.8.0,<2 resolves to whatever was current when the environment was built, which means two installations of the same release can be running SDKs a year apart.
The tagged window
The SDK repository contains exactly seven v1.x tags: v1.25.2, v1.25.3, v1.26.0, v1.27.0, v1.27.1, v1.28.0 and v1.29.0. Two of the pinned versions fall inside that range and can be read. The rest cannot.
Where the source was readable, both v1.25.2 and v1.27.1 declare the same protocol revision, 2025-11-25, so a version gap does not automatically mean a protocol gap. That is the reassuring half of the result and it only covers the versions that could be checked.
Method
Population. Clients drawn from the community awesome-mcp-clients list, of which 110 repositories were resolved and ranked by stars. The ten highest-starred entries that are open source, genuinely MCP clients, and declare an SDK dependency were carried forward. Closed-source clients — including some of the most widely used — are structurally out of scope, which is a real limit on what this can claim about the ecosystem.
Procedure. Each repository’s full file tree was fetched, manifests located, and the MCP SDK dependency read from source rather than from documentation. Several projects are monorepos where the dependency sits in a workspace package and is absent from the root manifest; those were found by walking the tree. Tag existence was checked against the SDK repository’s git refs.
What “no tag” does and does not mean. It means no tag of that name exists in the SDK repository as of the collection date. It does not establish that the version was never published — a package registry can serve a release the git history never tagged, and this audit had no network access to the registry to check. The claim is about auditability from source, not about whether the dependency resolves.
Also unverified. Protocol revision was read for the two versions with tags. The other four could not be read, so no protocol claim is made about them. Rust and Python SDKs use separate versioning and were not mapped.
What would change this
Checking the package registry would settle the largest open question, turning “no tag” into either “published but untagged” or something more serious. That is one API call away for anyone with network access to it.
Including closed-source clients would change the picture most, and cannot be done by this method at all. The most widely deployed MCP clients ship no manifest to read.
And this is a snapshot of a fast-moving dependency. The interesting version of this measurement is the same table six months from now, showing whether the spread narrows as the ecosystem matures or widens as clients diverge.
Collected 2026-09-04. First published 2026-09-04. Last revised 2026-09-04.