FastMCP 4: install with uv, and what the thin wheel actually pulls in

The wheel you install is a shell that resolves fastmcp-slim

Installing `fastmcp` does not put a package of that name on your disk. The wheel target in `pyproject.toml` selects nothing and excludes everything at the root:

[tool.hatch.build.targets.wheel]
bypass-selection = true
only-include = []
exclude = ["/*"]

The real work happens in a metadata hook, which pins a second distribution to the same version:

dependencies = [
    "fastmcp-slim[client,server]=={{ version }}",
]

So the published `fastmcp` is a thin shell whose job is to resolve `fastmcp-slim` with the client and server extras at an exactly matching version. That equality matters, because the two distributions have to be released in step and a mismatch shows up as a resolution error rather than as a missing module. Version and dependency lists are declared `dynamic`, filled in by `uv-dynamic-versioning` against git.

Extras decide which of the three pillars you actually get

Servers, Apps and Clients are presented as three equal pillars, but a base install does not carry all three. The optional dependency table declares each integration as its own extra on `fastmcp-slim`: `anthropic`, `apps`, `azure`, `code-mode`, `jev`, `gemini` and `openai`.

Consequence for anyone following a tutorial: an example that builds an App, or that imports an Anthropic or OpenAI integration, will not resolve from a bare install. You add the matching extra yourself, and the list of extras that exist is decided by the packaging table rather than by the documentation landing page.

That is a sensible trade for a framework spanning several model providers and hosting targets, and it keeps the size of what you install under your control in a single command. It is also where version-specific tutorials age fastest, since an extra can be renamed or absorbed between majors.

Four upgrade guides, which is what four breaking generations look like

The upgrade documentation is the clearest signal of how fast this project moves. Separate guides exist for arriving from FastMCP 3, from FastMCP 2, from MCP SDK v1 or v2, and from the low-level SDK v1 or v2. Four paths, each out of a different generation of the same idea.

The lineage explains the shape. FastMCP 1.0 was incorporated into the official MCP Python SDK in 2024, so something that began as a standalone convenience became the reference implementation, and the standalone package has since moved through majors 2, 3 and 4. The README also puts figures on that reach, claiming a million downloads a day and that some version of FastMCP powers 70% of MCP servers across all languages; those are the project's own claims and the repository holds nothing that substantiates them.

For an engineer the effect is practical: any tutorial predating the current major is suspect, and an upgrade is planned work rather than a version bump.

Four Python packages sit at the top level, and only one is named fastmcp

Contributors hunting for the code that actually executes will not find a top-level `fastmcp/` directory. The tree carries `fastmcp_slim/`, `fastmcp_remote/` and `fastmcp_tasks/`, and the packaging metadata points at `fastmcp-slim` as the distribution that carries the client and server code.

The justfile says the same thing differently. Its API reference recipe assembles a local editable install of that slim package with most of its extras enabled at once:

uvx --with-editable "{{api_ref_package}}" --refresh-package mdxify mdxify@latest --all --root-module fastmcp --nav-output docs/python-sdk-pages.json --exclude fastmcp.contrib

What that recipe documents is `fastmcp_slim/fastmcp`. When you are reviewing a change or debugging an import, `fastmcp_slim/fastmcp` is where to look. Generated API pages are cleaned out with a separate `rm -rf docs/python-sdk` recipe, so the reference is a build artifact and not a place to make edits.

SSO, tool-level RBAC and audit logs belong to Horizon

FastMCP's own scope is the application layer: build servers, connect clients, render apps. Governance sits one product over, in FastMCP Gateway, described as the enterprise MCP gateway built by the same team at Prefect. Branch previews with instant rollback, a private registry of a company's MCPs, SSO, tool-level RBAC, and audit logs all belong to that layer rather than to the framework.

Consequence: a self-hosted FastMCP deployment does not acquire those controls by installing the package. Per-tool authorisation and audit trails are yours to build, and the README points at a commercial gateway instead of documenting a built-in equivalent.

The same split shows up in language choice. The TypeScript counterpart lives in its own repository under the same team's maintenance, installs as `@prefecthq/fastmcp-ts`, and claims the same three pillars, so it is a parallel implementation rather than a binding layer over the Python one.

The whole doc set fits in one file, which may not fit in your model

Documentation ships in a machine-readable form alongside the site. `llms.txt` is essentially a sitemap listing every page, and `llms-full.txt` holds the entire documentation set, carrying an explicit warning that it may exceed the context window of your LLM.

That warning is the operative part. Handing the full file to an agent is the obvious move and the one most likely to overflow, so the sitemap becomes the routing layer and the full file is something you fetch selectively once you know the page you need.

The repository is arranged for the same readers. Alongside `AGENTS.md`, `CLAUDE.md` and `CONTRIBUTING.md` there are `.agents/` and `skills/` directories, and the contribution guide is paired with setup instructions and a validation workflow. Machine instructions are a maintained part of the tree here rather than something added afterwards.

Install is one uv command, and verification is two frozen runs

Adding FastMCP to a project takes a single command, and uv is the recommended route:

uv add fastmcp

Contributors and anyone verifying a checkout work through a justfile. Building syncs the environment, and the two checks that matter are pinned to the lockfile:

uv run --frozen pytest -xvs tests
uv run --frozen ty check

`--frozen` keeps the recorded `uv.lock` in charge instead of performing a fresh resolve, so a green local check corresponds to the dependency set that was locked. Documentation is served separately by a Mint dev server, with a distinct recipe for detecting broken links.

Supported interpreters run from 3.10 upward: `requires-python` is `>=3.10` and the classifiers run through Python 3.15. Releases are frequent, with v4.1.5 and the v4.2.0a2 pre-release published on 2026-11-01 and v4.1.6 on 2026-11-03, and the last push recorded on 2026-10-04.

Editorial conclusion

FastMCP suits a Python team that wants schema, validation and transport handled for it and is prepared to track a fast-moving API, pin dependencies and read the matching upgrade guide before bumping a major. It is a poor fit if you expect built-in SSO, tool-level RBAC or audit logs, since those sit in FastMCP Gateway rather than the package, or if you need the Apps and provider integrations without adding extras. Before you commit, check which extras your code imports, then confirm the version your tutorial targets against the v4.1.x releases published in November 2026.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. PrefectHQ/fastmcp on GitHub
3. Project website
4. README
5. Releases