FastMCP: a Python framework for MCP servers and clients

What FastMCP solves for Python teams wiring tools into LLMs

The Model Context Protocol defines how an LLM discovers and calls tools and reads data. Implementing that by hand means writing JSON schemas, argument validation, transport negotiation and the request lifecycle before you write a single line of business logic. FastMCP's claim is that you declare a tool as an ordinary Python function and the framework generates the schema, validation and documentation from the signature and docstring.

The README states that FastMCP 1.0 was incorporated into the official MCP Python SDK in 2024, and that the standalone project is now the maintained one. That history matters for adoption: if you already use the MCP Python SDK, some of what you are writing may be the same code under a different import. The README also says some version of FastMCP powers a large share of MCP servers across languages, but that is the project's own marketing claim, not something this article can verify.

The audience is narrow and clear. Python developers building MCP servers for an agent or IDE client, and Python developers who need a client that can talk to any MCP server, local or remote. If you are writing a server in Go or Rust, the project offers nothing for you; the README points TypeScript users at a separate repository.

The three pillars: servers, clients and in-conversation apps

The README organises the framework into servers, clients and apps. Servers wrap Python functions into MCP-compliant tools, resources and prompts. Clients connect to any MCP server with what the README calls full protocol support, both programmatically and through a CLI. Apps give tools interactive UIs rendered directly in the conversation.

That third pillar is the one to scrutinise. Rendering UI inside a conversation depends on the client supporting whatever surface the app expects, and the README does not say which clients do. Treat apps as the newest and least portable of the three, and validate against your actual client before designing around it.

The architecture visible in the repository is a thin top-level package over a slim core: pyproject.toml declares fastmcp-slim[client,server] as the base dependency, with optional extras for anthropic, apps, azure, code-mode, gemini, openai and tasks. So the install surface is layered. You get the client and server by default; provider integrations and the apps layer are opt-in. That is a sensible split, and it means the dependency weight of FastMCP depends on which extras you name.

Installing FastMCP and running a first tool

The README recommends uv and gives a single command. Run it inside your project so the dependency lands in your lockfile.

uv add fastmcp

After that, a server is defined by instantiating FastMCP and decorating a function. The README's own example is the shortest complete program: a tool named add that takes two integers and returns their sum.

from fastmcp import FastMCP

mcp = FastMCP("Demo")

@mcp.tool
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b

if __name__ == "__main__":
    mcp.run()

Running that file starts the server using the default transport. The README does not spell out the default transport or port in the excerpt available here, so check the installation and quickstart pages on gofastmcp.com before you assume a port number. The decorator is the mechanism to note: the function name becomes the tool name, the type hints become the argument schema, and the docstring becomes the description the model sees. Renaming the function renames the tool, which is a quiet way to break a client that hardcodes tool names.

For a client, the README says you can connect programmatically or through a CLI. A minimal programmatic connection takes a server URL. The README describes the client as handling transport negotiation, authentication and protocol lifecycle, but the exact constructor arguments are documented on the clients page, not in the README excerpt.

Where FastMCP is the wrong choice

Version churn is the first constraint. The repository is on v4.0.3, and the README links separate upgrade guides for FastMCP 3, FastMCP 2, MCP SDK v1, MCP SDK v2, and the low-level SDK in both v1 and v2. Six migration documents is not a neutral fact; it tells you the API has been reworked repeatedly and that pinning a major version is not optional. If your organisation cannot schedule migrations, this project will generate work.

Second, the framework is opinionated about Python. Tools are functions, and the ergonomics assume decorators and type hints. Teams that want to generate MCP schemas from another source, such as an OpenAPI document or a database catalog, are working against the grain of the primary abstraction, even if the providers directory suggests other entry points exist.

Third, the README's own framing is that best practices are built in. That is a benefit until you disagree with a default. Authentication, transport negotiation and lifecycle are managed for you, which means debugging a failure can require reading framework internals rather than your own code. The SECURITY.md file exists in the repository, but the README excerpt does not describe a threat model, so security-sensitive deployments should read that file directly.

Finally, the README's scale story points at Prefect Horizon, a separate commercial gateway from the same team. FastMCP itself is Apache-2.0 and standalone, but if your requirements include SSO, tool-level RBAC, audit logs and a private registry, the README routes you to the paid product, not to a feature of the library.

FastMCP compared with the low-level MCP Python SDK

The closest alternative is the official MCP Python SDK, and the relationship is unusual: the README states that FastMCP 1.0 was incorporated into that SDK in 2024. So the two are not independent implementations so much as an ancestor and a successor.

The difference in approach is the level of abstraction. With the low-level SDK you assemble the protocol surface yourself and control exactly what is sent and when. With FastMCP you hand over a typed Python function and let the framework derive the schema, validation and documentation. The trade is directness for speed: the low-level route gives you control over every field and no hidden defaults, while FastMCP gives you a working tool in a few lines and a framework to debug when the generated schema is not what you wanted.

FastMCP's own upgrade documentation treats the SDK as a migration source, listing guides for MCP SDK v1 and v2 and for the low-level SDK in both versions. That is the clearest signal of intended use: FastMCP expects to be the layer you move up to, not the layer you drop down from. If you have already built against the low-level SDK and your tool surface is small, the migration cost may exceed the benefit. If you are starting from nothing and your tools are Python functions, the framework removes a large amount of boilerplate.

Licence, maintenance and the real cost of upgrading

FastMCP is licensed Apache-2.0, declared in both the LICENSE file and the pyproject.toml license field. Apache-2.0 is a permissive licence with an explicit patent grant and requires you to preserve notices. That is a general description of the licence text, not legal advice; if you redistribute FastMCP inside a product, have your own counsel read the terms.

One packaging detail worth knowing: the wheel is built with hatchling and uv-dynamic-versioning, and the base dependency is fastmcp-slim pinned to the same version. The extras are declared per provider. That means an upgrade moves the slim core and your chosen extras together, and a mismatch between them is a plausible failure mode if you pin the extras independently.

On maintenance, the last push to the repository was on 2026-09-09, and releases v4.0.1, v4.0.2 and v4.0.3 landed within the first week of September 2026. The repository is not archived. That is a fast release cadence, which cuts both ways: fixes arrive quickly, and so do behaviour changes. The practical upgrade cost is not the install command, it is the migration guide. Before adopting, read the guide that matches your starting point, because the README lists six of them and they are the documentation the project itself considers necessary.

Editorial conclusion

Adopt FastMCP if your team writes Python and needs to expose functions, data sources or prompts to an LLM client without hand-writing MCP protocol plumbing. Skip it if you need a language other than Python or TypeScript, or if you cannot absorb a major-version migration: the README links separate upgrade guides for FastMCP 3, FastMCP 2 and the low-level SDK, which tells you the API has moved more than once. Verify first that your Python is 3.10 or newer, that the extras you need (apps, anthropic, openai, azure, gemini, code-mode, tasks) are the ones you actually install, and that your deployment target can reach gofastmcp.com for the docs your team will read.

Frequently asked questions

Official sources

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