FastMCP vs MCP Python SDK: Which to Use in 2026

FastMCP and the MCP Python SDK share a name and a decorator API, but they are different packages with different scope. The official mcp package bundled FastMCP 1.0 as its high-level server class, while standalone FastMCP is the broader toolkit for clients, composition, proxying, and OpenAPI or FastAPI integration. Use the official SDK for the stable reference server path, and choose standalone FastMCP when those extra capabilities matter.

The default install has moved, and that changes the Python MCP SDK vs FastMCP question. I re-ran my clean-install test on an M1 Mac on October 5, 2026. A plain uv pip install "mcp[cli]" resolved mcp 2.3.0 with no prerelease flag. The 2.x line renames the bundled class to MCPServer and drops the old mcp.server.fastmcp import path entirely. A plain uv pip install fastmcp resolved 4.0.11, which now pulls in that same mcp 2.3.0 underneath. This corrects the first version of this page. When I ran the test on August 2, 2026, fastmcp 3.4.5 still pulled in mcp 1.29.0, and I wrote that FastMCP bundled the v1 SDK. FastMCP no longer pins v1.

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 got 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. That line was already the default install on August 2, 2026, and on October 5 it still was, at 2.3.0. The two projects no longer share a class name at all.

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.

Version 1.x is in maintenance mode. It receives critical fixes but no new features, and the line has moved past 1.28.1: in August a fastmcp 3.4.5 install pulled in mcp 1.29.0 as its transitive dependency. A fresh fastmcp install no longer brings in the v1 line at all, so you now get it only by asking for it with "mcp[cli]<2". That stability is deliberate. Teams that need a boring, officially backed dependency choose v1.x precisely because it does not move.

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 reached general availability on February 18, 2026 under the release title "Three at Last." In the GA announcement, Lowin summarized the beta directly: "the architecture held up, the upgrade path was smooth, and we're shipping it." The cycle 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 rather than a side project. 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. The 3.x line is no longer the newest: a plain install resolved 4.0.11 on October 5, 2026, and in that version from fastmcp import FastMCP and both decorator forms still worked.

What the Bundled FastMCP (mcp) Still Gives You

On the v1.x line, 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. According to the FastMCP docs, it does not include server composition, universal proxying, client-side sampling, or OpenAPIProvider; those remain standalone-only.

That snippet now needs the v1 line installed on purpose. On October 5, 2026, neither of my clean venvs could import mcp.server.fastmcp: the mcp 2.3.0 environment could not, and neither could the fastmcp 4.0.11 environment, which carries the same mcp 2.3.0. In August the fastmcp environment still exposed the old path; that side effect is gone.

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; Lowin's beta post presents this as the primary use case the 3.0 Provider architecture was built around. 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's docs report roughly 1 million downloads a day and claim it powers about 70% of MCP servers across all languages. Both figures are self-reported by Prefect, so treat them as an adoption signal, not an audited count.

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.

The rename is a hard break, not a deprecation. In my August 2 run, from mcp.server.fastmcp import FastMCP raised ModuleNotFoundError under mcp 2.0.0, while from mcp.server import MCPServer succeeded. The October 5 re-run under 2.3.0 gave the same result: the old import failed and MCPServer imported. 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 registered 3 tools once I used the correct form.

What a plain install actually gives you (measured October 5, 2026)

The finding this page first led with no longer holds. On August 2, 2026, fastmcp 3.4.5 pulled in mcp 1.29.0, a full major version behind the 2.0.0 a direct SDK install resolved, so I wrote that the two packages shipped different protocol libraries underneath. On the October 5, 2026 re-run, fastmcp 4.0.11 pulled in mcp 2.3.0, the same version a direct SDK install resolved. FastMCP no longer pins the v1 SDK, so the two packages now differ in API and features on top of the same protocol library. The table below is the October run.

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 differences are the import line and the decorator form. The extra 30 packages, and 65 MB of site-packages against 41 MB, buy FastMCP's provider architecture, not a smaller server.

Do not choose on import speed. In the October run, the median cold import was 419.2 ms for fastmcp and 693.1 ms for the SDK's mcp.server.mcpserver, a wider gap than August showed, but that is still one run on one machine. In August, two back-to-back runs of the same benchmark on an idle machine put the gap at 18.5 ms and 114.1 ms, and fastmcp's own median moved from 601.6 ms to 691.6 ms between them. With that much run-to-run drift, I would re-measure on your own hardware before letting import time pick a package.

How I tested this

All measured figures come from one script. I first ran it on August 2, 2026 and re-ran it on October 5, 2026, both times on a MacBook Air M1 (arm64) with 8 GB of memory, Python 3.13.5, and uv. It builds two fresh uv venvs, installs fastmcp in one and "mcp[cli]" in the other with no prerelease flags, and then records the resolved versions, the mcp version that fastmcp pulls in, which import paths and decorator forms work, site-packages size, installed package count, and the median cold import time over fifteen runs. It also counts the non-blank lines of an equivalent three-tool server for each library and checks that both servers register their tools.

Because the script builds both venvs from scratch, each run reflects whatever a plain install resolved that day, which is how the re-run caught the dependency change. I did not connect either server to a client, test transports or auth, or measure request throughput. I also did not review what FastMCP 4.x changed beyond what the script records; the feature rows in the comparison table below come from the project documentation and the 3.0 announcements, not from my runs. These are single-machine results, so re-run the script before applying them to another setup. The October 5 test record has every current measurement, the August 2 test record is kept unchanged so you can see what moved, and the harness script sits in the same folder with both server files.

Comparison: Bundled vs Standalone, Before and After the Rename

Here is how the three options line up, based on the SDK repository and the two FastMCP 3.0 announcements. A plain uv add fastmcp now installs the 4.x line, so treat the standalone column as the 3.x baseline:

In practice the install decision is one of three commands: uv add "mcp[cli]<2" for the stable v1 API, uv add "mcp[cli]" for current SDK v2 and MCPServer, or uv add fastmcp for standalone composition and providers. If from mcp.server.fastmcp import FastMCP raises ModuleNotFoundError, you installed v2 and need to migrate or pin v1. As of the October 5 run, that includes an environment where you only installed fastmcp, because fastmcp 4.0.11 brings in mcp 2.3.0.

Which Should You Use?

Use the 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 and runner rewrite brings native OpenTelemetry now and more parity later.

Use standalone FastMCP if you need to compose multiple servers, proxy a third-party server, or auto-generate tools from an existing REST API. It is stable (3.x reached GA in February 2026, and a plain install now resolves 4.0.11), actively maintained by PrefectHQ, and has the broadest adoption of the two by the project's own download numbers.

Choosing FastMCP no longer keeps you on the v1 protocol library. Since both installs now sit on mcp 2.3.0, the choice comes down to the features above, not to which SDK generation you end up with.

Pin deliberately, because the default moved. uv add "mcp[cli]" now installs 2.3.0, so an unpinned dependency that worked in June will fail on the mcp.server.fastmcp import today. Code that relied on fastmcp to bring in the v1 SDK breaks the same way since fastmcp moved to mcp 2.3.0. Stay on the v1 line with "mcp[cli]<2" until you have migrated to MCPServer, then drop the bound. If your code imports from mcp directly, declare mcp in your own dependencies rather than relying on whichever version fastmcp brings in.

I expect the feature gap with standalone FastMCP to narrow after v2 stabilizes, because v2 adds OpenTelemetry and multi-round-trip support natively. The rename cuts the other way for existing code: anything written against the v1 mcp.server.fastmcp.FastMCP import will not survive the upgrade unchanged.

Whichever package you choose, test the server before wiring it into a client: the MCP Inspector guide shows how to list and call its tools from the browser UI or a scriptable CLI.

Which FastMCP package are you importing?

The name is ambiguous because the official Python SDK bundled a FastMCP interface for its whole v1 life, while the standalone FastMCP project kept its own release line. In a new repository, record the installed distribution, import path, and version before comparing APIs. In an existing service, prototype one representative tool and its transport and auth behavior on both versions, then test the migration under your actual client; FastMCP publishes a migration guide for moving from MCP SDK v1. A matching name alone does not establish API or deployment parity.

FAQ

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.

Related coverage

• FastMCP vs FastAPI-MCP: Which Python MCP Library?
• MCP Inspector: How to Use It, CLI Mode and Fixes (v2 Tested)
• MCP vs RAG: Differences, Use Cases, and a 12-Query Test, for deciding when an MCP tool fits better than document retrieval

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
• FastMCP migration guide - https://gofastmcp.com/getting-started/upgrading/from-mcp-sdk-v1
• MCP Python SDK - https://github.com/modelcontextprotocol/python-sdk