MCP's FastMCP rename breaks first in CI and on the newest contributor's laptop

`pip install` sees a requirements line that reads `mcp>=1.0`. Python does not require an upper bound, so the resolver takes the newest release available and nothing tells it to stop at 1.x ^[4]. The failure appears at import time, in whichever environment runs the next fresh install. The dev.to post that documented the break says that is usually a CI job or a new contributor's machine ^[5].

All of this happens while the affected repository sits untouched ^[6]. The confirmation is a GitHub issue filed against jupyter-mcp-server, titled "mcp 2.0.0 breaks imports: FastMCP renamed to MCPServer, module moved," where only dependency resolution had changed ^[7]. The commit responsible sits in another project's history ^[7].

A 2.0.0 release is where a maintainer is allowed to move an import path, and the SDK moved `mcp.server.fastmcp` wholesale to `mcp.server.mcpserver` without leaving a shim on the old path ^[1]. The migration guide puts it in one line: "FastMCP is now MCPServer, and there is a first-class Client." ^[2] The decorator API itself did not change, and the low-level `Server` was rebuilt around a shared dispatcher engine ^[3]. With the decorators intact, the migration for most projects is the import statement ^[3], and the missing piece was the ceiling in the consumer's requirements file ^[4].

The other change in that release is silent. The default `serverInfo.name` went from `"FastMCP"` to `"mcp-server"`, so the identity string every connected client sees changed with no exception thrown ^[8]. The post says the symptom surfaces three weeks later as "wait, why does our logging dashboard show a different server name than last month." ^[9]

The post also cites general-ecosystem data that 20-28% of minor and patch releases marketed as safe introduce breaking API changes, with renames a recognised category ^[10]. At the ends of that range, that is one break in every four to five such upgrades ^[11]. The post does not identify the study behind the figure. The range also covers minor and patch releases, while mcp 2.0.0 is a major bump, so the number describes a different class of upgrade than the one it is illustrating ^[15]. For it to transfer to your dependency list, your packages would have to ship at comparable rates and treat renames as fair game under a minor tag.

The design argument is the author's own: a two-tier tool layout, one guided and validated path plus one raw passthrough, contains this class of breakage, because the guided tier absorbs an SDK migration internally without changing its contract to callers ^[12]. The author reports the rename did not break the server he maintains, which exposes 70 Highcharts chart types to AI agents, and that he settled on the layout before he knew about the rename ^[13]. Someone still does the migration inside the guided tier, and the callers' side holds steady ^[12].

Two different things carry the name FastMCP. The renamed one is the SDK's built-in class ^[1]. The standalone framework Jeremiah Lowin built is a separate codebase at v4.0, unaffected by this release, and it predates the SDK class it inspired ^[14].