FastMCP: a Python framework for building MCP servers, clients and in-conversation apps
🚀 The fast, Pythonic way to build MCP servers and clients.
At a glance
- What is it?
- FastMCP wraps Python functions into MCP tools, resources and prompts, and ships a client for connecting to any MCP server. It is the fastest route from a function to a working MCP endpoint, and the README itself points to a paid gateway once you outgrow a single process.
- Who is it for?
- Adopt FastMCP if you are writing Python and want an MCP server or client that behaves correctly without hand-writing schemas and transport handling. Do not adopt it if you need a language other than Python or TypeScript, or if a single long-running server with no client-side needs is already served by something you maintain.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The boilerplate FastMCP removes, and who feels it
An MCP server has to declare a tool, produce a JSON schema for its arguments, validate incoming calls against that schema, and keep a protocol session alive over a transport. Done by hand, that is a lot of code that has nothing to do with what the tool actually does. FastMCP's answer is a decorator. The README's opening example is four lines of logic: an instance of FastMCP, an @mcp.tool decorator on a function named add that takes two ints and returns an int, and an mcp.run() call under a __main__ guard. The docstring becomes the tool description. The type hints become the schema. The README states this directly: "Declare a tool with a Python function, and the schema, validation, and documentation are generated automatically."
The audience is Python developers who already know what they want the tool to do and do not want to learn the wire format first. That includes people exposing an internal function to an assistant, and people writing the client side, where the README says connecting to a server takes a URL and that transport negotiation, authentication and protocol lifecycle are handled for you. The project is not aimed at someone who needs to inspect or hand-tune the protocol messages, and the README does not present it that way.
Three pillars: servers, clients, and apps rendered in the conversation
The README divides the project into servers, clients and apps. Servers expose tools, resources and prompts. Clients connect to any MCP server, described as local or remote, programmatic or CLI. Apps are the newest of the three and the least conventional: they give tools interactive UIs rendered directly in the conversation. That third pillar is the one that separates FastMCP from a plain protocol wrapper, and it is also the one the README covers in the fewest words, pointing to a documentation page rather than showing a code sample. If interactive tool UIs are what drew you in, the README alone will not tell you how they are built.
The three pillars share one package. There is no separate install for the client, which matters if you want to test your own server from Python in the same test suite. The README also notes an official TypeScript counterpart, fastmcp-ts, maintained by the same team, installed with npm install @prefecthq/fastmcp-ts, with the same three pillars. That is a real answer to the language question rather than a redirect to a community port.
Installation, the __main__ guard, and version drift
The README recommends uv and gives one command: uv add fastmcp. It then points to an installation guide for verification and upgrading rather than repeating those steps. The server example ends with mcp.run() inside an if __name__ == "__main__" block, which is the shape you should copy: the module can be imported by a test harness without starting a server as a side effect.
The upgrade surface is the part to read carefully before you start. The README links separate migration guides for FastMCP 3, FastMCP 2, MCP SDK v1, MCP SDK v2, low-level SDK v1 and low-level SDK v2. Six distinct upgrade paths is not a documentation flourish; it reflects that this project has absorbed and then diverged from the official SDK, and that code written against an older entry point will not simply keep working. The release history supplied here shows v4.0.1, v4.0.2 and v4.0.3 landing within the first five days of September 2026, so patch releases arrive quickly. Pin the version in your lockfile and read the guide for your starting point rather than assuming compatibility.
The provenance claim, and how much weight to give it
The README makes two claims about adoption: that FastMCP 1.0 was incorporated into the official MCP Python SDK in 2024, and that the standalone project is downloaded a million times a day, with some version of FastMCP powering 70% of MCP servers across all languages. Those are the vendor's own numbers and this review cannot verify them. Treat them as context for why the API is shaped the way it is, not as a reason to adopt.
The more useful fact is the relationship with the official SDK. If FastMCP 1.0 went into the SDK and then continued as a standalone project, the two codebases now have separate release cadences and separate APIs. That is exactly why six upgrade guides exist. It also means a tutorial you find online may be written against the SDK's bundled version rather than the standalone package, and the imports will look similar enough to be confusing. Check the guide that matches your dependency before copying code.
Where FastMCP is the wrong tool
The README does not describe a failure mode, but the structure of the project implies several boundaries. The first is language. Python and TypeScript are covered by first-party packages; anything else is outside what this material documents. If your service is Go or Rust, FastMCP is not a candidate regardless of how the Python API reads.
The second is scale across teams. The README hands that problem to a different product. Prefect Horizon is described as an enterprise MCP gateway for scaling servers and tools across teams, with centralized governance over deployment, discovery, security and use, plus SSO, tool-level RBAC, audit logs and observability. None of that is in the FastMCP package as described here. The README is explicit that the two are built by the same team, and the Horizon section is a call to action with tracking parameters. So the honest reading is that FastMCP covers the application layer and the governance layer is a commercial product. If your requirement is a private registry of approved MCPs with per-tool permissions, installing fastmcp does not get you there.
The third boundary is thinner than it looks: the README says clients connect to any MCP server, but "any" here means any server speaking the protocol, not any server with any authentication scheme. Authentication is listed among the things managed for you, but the README does not enumerate which mechanisms are supported. That is a question for the client documentation, not the README.
The low-level SDK and the TypeScript package as alternatives
The most direct alternative is the official MCP Python SDK's low-level interface, which the README treats as a migration source with its own v1 and v2 upgrade guides. The difference in approach is where the abstraction sits. The low-level SDK has you register handlers and describe capabilities yourself, which means you see the protocol and control it, at the cost of writing the schema and validation layer that FastMCP generates from type hints. If you need to do something the decorator model does not express, the low-level path is the escape hatch, and the existence of a migration guide from it suggests people move in both directions.
The other alternative is fastmcp-ts. It is not a competitor so much as a sibling: same team, same three pillars, different runtime. The practical difference is your deployment target, not the feature set. Choosing between them is choosing your language, and the README presents them as parallel rather than as one being the recommended path.
Licence, maintenance, and what the release cadence implies
FastMCP is Apache-2.0, a permissive licence that permits commercial use and modification, with the usual requirements around notices and the absence of a trademark grant. This is general information, not legal advice; if you are vendoring or redistributing the package, read the LICENSE file at the repository root, which the README links in its badge row.
On maintenance, the signals available here are activity rather than stability. The default branch is main, the repository is not archived, and the most recent push in the supplied data is 2026-09-09. Three patch releases shipped between 2026-09-02 and 2026-09-05, each with a short codename. A patch cadence that tight usually means regressions are being fixed quickly, and it also means your lockfile matters. The upgrade guides for four major lines tell you the same thing from the other direction: this is a project that has changed its surface more than once, and the cost of staying current is reading a migration document, not just bumping a version string. Budget for that reading time when you plan the work, especially if you are coming from an SDK-bundled copy rather than a pinned standalone release.
Editorial conclusion
Adopt FastMCP if you are writing Python and want an MCP server or client that behaves correctly without hand-writing schemas and transport handling. Do not adopt it if you need a language other than Python or TypeScript, or if a single long-running server with no client-side needs is already served by something you maintain. Before committing, read the upgrade guide for the major version you are coming from, check which FastMCP version your MCP SDK dependency pins, and confirm whether Horizon is required for the multi-team governance features you are counting on. The framework and the gateway are separate products from the same vendor.
Community notes