Lowin kept building a separate, more ambitious FastMCP under his own name. It returned to standalone status as FastMCP 2.0 in April 2025, then reached a stable 3.0 release on February 18, 2026, moving to the PrefectHQ organisation. Then, on June 30, 2026, the official SDK shipped its 2.0 line, which renames its own bundled class from FastMCP to MCPServer; that release is now the default install. (Source: FastMCP 3.0 GA Launch)
Key takeaways:
- FastMCP 1.0 ships inside the official MCP Python SDK as
mcp.server.fastmcp.FastMCP(v1.x, stable, maintenance mode). - Standalone FastMCP reached 3.0 GA on February 18, 2026, and the project now lives at
github.com/PrefectHQ/fastmcp.
The official SDK's v2.0 is no longer a beta: uv pip install "mcp[cli]" with no prerelease flag resolves mcp==2.0.0 as of August 2, 2026. It renames the bundled class to MCPServer and drops the old mcp.server.fastmcp import path entirely.
- Use bundled
mcpfor a minimal, Anthropic-maintained server; use standalone FastMCP for composition, proxying, or OpenAPI-generated servers.
The Short Answer: Two Projects, One Name, and a Rename in Progress
FastMCP began in late 2024 as Jeremiah Lowin's decorator-based wrapper around the Model Context Protocol, the spec that lets AI assistants call external tools and data sources. His pitch was that "life's too short for boilerplate." Anthropic liked the API enough to fold FastMCP 1.0 into the official modelcontextprotocol/python-sdk, so anyone installing that SDK gets from mcp.server.fastmcp import FastMCP for free.
On June 30, 2026, the official SDK's 2.0 line renamed its own bundled class to MCPServer and removed the mcp.server.fastmcp path. As of August 2, 2026 that line is the default install, so the two projects no longer share a class name at all. (Source: MCP Python SDK)
How FastMCP 1.0 Became Part of the Official SDK
The official MCP Python SDK is the modelcontextprotocol organization's reference implementation, distributed as the mcp package. It ships FastMCP 1.0's decorator API as its recommended high-level interface: install uv add "mcp[cli]" and you get schema generation, validation, and stdio, SSE, and Streamable HTTP transports out of the box (Source: MCP Python SDK).
Version 1.x is in maintenance mode. It receives critical fixes but no new features, and the line has moved past 1.28.1: a current fastmcp install pulls in mcp 1.29.0 as its transitive dependency. That stability is deliberate: teams that need a boring, officially backed dependency choose v1.x precisely because it does not move. (Source: MCP Python SDK)
FastMCP 3.0 Is Now Stable: What Changed Since Beta
FastMCP 3.0 spent about a month in beta after its January 20, 2026 announcement, then went general availability on February 18, 2026 under the release title "Three at Last." Lowin summarized the beta results directly: "the architecture held up, the upgrade path was smooth, and we're shipping it" (Source: FastMCP 3.0 GA Launch). The beta ran two betas and two release candidates, drew 21 new external contributors, and logged more than 100,000 opt-in pre-release installs before GA.
The GA release also marked a governance shift. The repository moved from the personal jlowin/fastmcp to PrefectHQ/fastmcp, reflecting that Prefect now backs the project as core infrastructure, not a side project (Source: FastMCP 3.0 GA Launch). The architecture itself rests on three primitives: Components (Tools, Resources, Prompts), Providers (where components come from, including OpenAPIProvider and the hot-reloading FileSystemProvider), and Transforms (middleware that reshapes Provider behavior). The decorator surface is unchanged, so @mcp.tool() still works exactly as it did in 2.x. The 3.4.2 release (June 6, 2026) folded in a Starlette floor bump to close CVE-2026-48710; as of August 2, 2026 a clean uv pip install fastmcp resolves 3.4.5.
What the Bundled FastMCP (mcp) Still Gives You
A minimal bundled server needs only a few lines:
from mcp.server.fastmcp import FastMCP app = FastMCP("my-server") @app.tool() def add(a: int, b: int) -> int: """Add two numbers.""" return a + b
That covers schema generation, input validation, and the transport layer for a server that exposes a fixed set of tools. It does not include server composition, universal proxying, client-side sampling, or OpenAPIProvider; those remain standalone-only (Source: FastMCP Docs).
Operator note (first-hand): re-measured August 2, 2026 on an Apple M1, macOS 26.3, Python 3.13.5. A clean uv venv plus uv pip install fastmcp resolves fastmcp==3.4.5, and a separate venv running uv pip install "mcp[cli]" resolves mcp==2.0.0 with no prerelease flag. The two packages are not interchangeable installs: the fastmcp venv still exposes the old mcp.server.fastmcp path, the SDK venv does not.
What Standalone FastMCP 2.x/3.x Adds
Standalone FastMCP (pip install fastmcp) covers everything the bundled class does, plus the features production teams actually ask for. Server composition mounts multiple FastMCP servers into one parent with path prefixes, which is how most MCP aggregators are built. Universal proxying wraps any MCP server, including third-party or non-FastMCP servers, as a FastMCP instance regardless of the backend transport.
OpenAPIProvider generates MCP tools directly from a FastAPI app or an OpenAPI spec, so a REST API becomes a tool server without hand-written handlers. Client-side sampling lets a server tool call back into the connected client's LLM through ctx.sample(), which is the primitive behind agent-to-agent collaboration patterns. FastMCP reports roughly 1 million downloads a day and claims to power about 70% of MCP servers across all languages; both figures are self-reported by Prefect and should be read as adoption signal, not an audited count (Source: FastMCP Docs).
The Official SDK's v2.0 Renames FastMCP to MCPServer
This is the change that matters most for anyone still confused by the shared name. The SDK's 2.0 line replaces the session-centric v1 internals with a dispatcher and runner pipeline, and renames the bundled FastMCP class to MCPServer. It first shipped as 2.0.0b1 on June 30, 2026 and is now the default install, so any tutorial that opens with from mcp.server.fastmcp import FastMCP fails on a fresh environment. (Source: MCP Python SDK)
Operator note (first-hand): the rename is a hard break, not a deprecation. On the same August 2 run, from mcp.server.fastmcp import FastMCP raises ModuleNotFoundError under mcp 2.0.0, while from mcp.server import MCPServer succeeds. The decorator changed too: MCPServer rejects a bare @mcp.tool with a TypeError telling you to use @mcp.tool(), whereas standalone FastMCP accepts both forms. Both servers register 3 tools once the correct form is used.
Comparison: Bundled vs Standalone, Before and After the Rename
| Feature | Bundled mcp v1.x (maintenance) | Bundled mcp 2.0 (current) | Standalone FastMCP 3.x (GA) |
|---|---|---|---|
| Install | uv add "mcp[cli]<2" | uv add "mcp[cli]" | uv add fastmcp |
| Server class | FastMCP | MCPServer | FastMCP |
| Decorator tools/resources | yes | yes | yes (LocalProvider) |
| Server composition | no | no (not documented) | yes |
| Universal proxying | no | no (not documented) | yes |
| OpenAPI auto-gen | no | no (not documented) | yes (OpenAPIProvider) |
| Client-side LLM sampling | no | no (not documented) | yes |
| Hot reload | no | no | yes (FileSystemProvider) |
| OpenTelemetry native | no | yes (default-on) | yes |
| Stability | stable, maintenance mode | stable, default install | stable (GA Feb 18, 2026) |
| Maintained by | modelcontextprotocol org | modelcontextprotocol org | PrefectHQ |
| Official Anthropic backing | yes | yes | no |
(Sources: MCP Python SDK, FastMCP 3.0 GA Launch, FastMCP 3.0 Beta)
Which Should You Use?
Use bundled mcp v1.x if you need a simple server exposing a fixed set of tools, want to stay on the officially maintained package, or have constraints that limit third-party dependencies. It will not gain composition or proxying on its own, but v2's dispatcher/runner rewrite brings native OpenTelemetry now and more parity later.
Use standalone FastMCP 3.x if you need to compose multiple servers, proxy a third-party server, or auto-generate tools from an existing REST API. It is stable, actively maintained by PrefectHQ, and has the broadest adoption of the two by the project's own download numbers.
Pin deliberately, because the default moved. uv add "mcp[cli]" now installs 2.0.0, so an unpinned dependency that worked in June will fail on the mcp.server.fastmcp import today. Stay on the v1 line with "mcp[cli]<2" until you have migrated to MCPServer, then drop the bound.
Inference: because v2 both renames the bundled class and adds OpenTelemetry and multi-round-trip support natively, the feature gap with standalone FastMCP will likely narrow after v2 stabilizes, but the rename means code written against today's mcp.server.fastmcp.FastMCP import will not survive the upgrade unchanged (Source: MCP Python SDK).
FAQ
Is FastMCP part of the official MCP Python SDK?
Yes, in v1.x: FastMCP 1.0 was incorporated into the official SDK and is available as from mcp.server.fastmcp import FastMCP. That import path is gone in 2.0, which is now the default install, and the bundled class is renamed MCPServer.
FastMCP vs MCP SDK: what changed in v2.0?
Version 2.0 rewrites the SDK's internals around a dispatcher and runner pipeline and renames the bundled FastMCP class to MCPServer. It shipped as 2.0.0b1 on June 30, 2026 and is now the default mcp install. Standalone FastMCP is unaffected: it reached a stable 3.0 in February 2026 and keeps its own FastMCP class.
What is the difference between MCP and FastMCP in Python?
mcp is the official Model Context Protocol Python SDK: the reference implementation, maintained by the modelcontextprotocol organization, with FastMCP 1.0 bundled inside v1.x. fastmcp is the standalone framework under PrefectHQ that adds composition, proxying, OpenAPI generation, and client-side sampling. Same decorator API at the core, different packages and feature depth.
Should I use mcp or fastmcp for production?
For a simple, fixed-tool server: bundled mcp v1.x. For a server that needs composition, proxying, or OpenAPI-generated tools: standalone fastmcp. Both are production-grade today, so the choice comes down to which features you actually need.
Does FastMCP 3.0 work with FastAPI?
Yes. FastMCP 3.0's OpenAPIProvider ingests a FastAPI app or any OpenAPI spec and generates MCP tools automatically from the route definitions, which is the primary use case the 3.0 Provider architecture was built around (Source: FastMCP 3.0 Beta).
What is the best Python MCP library?
There is no single best. The official mcp SDK is the reference implementation and the safest default for a simple, fixed-tool server, while standalone fastmcp (PrefectHQ) is the most feature-complete framework, adding composition, proxying, and OpenAPI generation. Pick mcp for minimal servers, fastmcp when you need those extras.
Is MCP better than a plain API?
They solve different problems. A REST or OpenAPI endpoint exposes data to any HTTP client; MCP standardizes how an agent discovers and calls tools with typed schemas, so you skip writing per-model glue. They are complementary, not rivals: FastMCP 3.0 can even generate MCP tools directly from an existing FastAPI or OpenAPI app.
What a plain install actually gives you (measured August 2, 2026)
Every figure below comes from one script run on an Apple M1, macOS 26.3, Python 3.13.5. It builds both venvs from scratch and is re-runnable: fastmcp-vs-mcp-sdk benchmark.
The finding that matters most is not in either project's docs: standalone FastMCP still bundles the v1 line of mcp. Installing fastmcp gets you mcp 1.29.0 as a transitive dependency, a full major version behind the 2.0.0 you get from installing the SDK directly. So the two packages do not just differ in API, they ship different protocol libraries underneath.
| Measurement | fastmcp 3.4.5 | mcp 2.0.0 |
|---|---|---|
| Bundled mcp version | 1.29.0 | n/a |
| mcp.server.fastmcp importable | yes | no |
| from mcp.server import MCPServer | n/a | yes |
| Bare @mcp.tool accepted | yes | no, raises TypeError |
| site-packages | 68 MB | 42 MB |
| Installed packages | 66 | 36 |
| Equivalent 3-tool server | 16 lines | 16 lines |
Operator note (first-hand): the ergonomics are closer than the package sizes suggest. The same three-tool server is 16 non-blank lines in both libraries and registers 3 tools in each; the only source difference is the import line and the decorator form. The 26 MB and 30-package gap buys FastMCP's provider architecture, not a smaller server.
Operator note (first-hand): do not choose on import speed. Across two consecutive runs of the same benchmark on an idle machine, the median cold import gap between the two libraries moved from 18.5 ms to 114.1 ms, with fastmcp's own median swinging 601.6 ms to 691.6 ms. Both land in the 600 to 720 ms range and the difference is inside run-to-run noise, so any article ranking them by import time is reporting scheduler jitter. (Source: AgenticWire benchmark)
Related coverage
- How to Deploy a FastMCP Server to Production in 2026
- FastMCP from OpenAPI: Build an MCP Server from Your Existing API
- FastMCP OAuth Token Validation: Server-Side Patterns and Pitfalls
- A2A vs MCP: Which Agent Protocol Should You Pick?
- FastAPI vs FastMCP: Which Python MCP Library to Use
- How to Test a FastMCP Server with Pytest
References
- FastMCP 3.0 Beta - https://jlowin.dev/blog/fastmcp-3
- FastMCP 3.0 GA Launch - https://jlowin.dev/blog/fastmcp-3-launch
- FastMCP Docs - https://gofastmcp.com
- MCP Python SDK - https://github.com/modelcontextprotocol/python-sdk




