FastMCP 3.x and Where the Spec Is Heading

Past the official SDK: what the standalone FastMCP 3.x framework adds, when to reach for it, and what the 2026 spec revisions — Tasks, MCP Apps, a stateless core — are bringing next.

Series: Building MCP Servers — Part 12 of 12

We built the whole series on the official SDKs, and for learning the protocol that was the right call: they map closely to the spec, carry few dependencies, and won’t go anywhere. But two things sit just past their edge, and you should know they exist: a higher-level Python framework called FastMCP 3.x, and the moving target of the spec itself. This last post is a map of the frontier, not a tutorial: where to look when the official SDK isn’t quite enough, and what’s coming.

Two things named FastMCP

This trips people up, so let’s settle it. The FastMCP you imported all series (from mcp.server.fastmcp import FastMCP) is the high-level server inside the official Python SDK. It got there because the original FastMCP (version 1) was folded into the SDK as its ergonomic front door. Its author kept going independently, and the standalone fastmcp package is now on 3.x — a much larger framework that builds well past where version 1 stopped. So “FastMCP” names two related things: the spec-faithful core in the official SDK, and the batteries-included framework you install separately.

The standalone version’s hello-world looks almost identical — note the bare @mcp.tool and a polished in-process client:

from fastmcp import Client, FastMCP

mcp = FastMCP("demo")

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

# FastMCP's client can talk to the server object directly, no transport:
async with Client(mcp) as client:
    result = await client.call_tool("add", {"a": 2, "b": 3})
    print(result.data)  # 5

What 3.x adds

The reason to reach for the standalone framework is everything stacked on top of that familiar core. The headline pieces, as of 3.x: server composition — mount and proxy other MCP servers to compose a big surface from small ones; authentication providers that wire up real OAuth without hand-rolling a verifier; generation from existing APIs, turning an OpenAPI spec or FastAPI app into an MCP server; OpenTelemetry for tracing in production; a first-class client and testing story like the in-process Client above; and deployment helpers for running servers as services. It’s the difference between a protocol library and an application framework.

There’s no TypeScript equivalent at this layer — the official @modelcontextprotocol/sdk is the framework on that side, and you compose the extras (Express, your auth middleware, your telemetry) yourself, much as we did across this series.

When to use which

Both are good; they aim at different moments.

  • Official SDK (what we used) — when you’re learning the protocol, want a small dependency footprint, need to stay close to the spec, or are writing TypeScript. It’s the honest baseline.
  • FastMCP 3.x — when you’re running many servers, want composition and proxying, need OpenAPI generation or built-in auth and telemetry, and you’re on Python. It earns its weight at scale.

A reasonable path is to start on the official SDK (everything in this series transfers directly) and adopt FastMCP 3.x when you feel yourself rebuilding its features by hand.

Where the spec is heading

MCP is young and moving, so a snapshot dates fast — but the direction is clear from the public roadmap and the 2026-07-28 release candidate. A few themes worth watching, all forward-looking rather than something to build on today:

  • A stateless protocol core, making it cleaner to run servers as ordinary horizontally-scaled services.
  • Tasks — first-class support for long-running operations that outlive a single request, instead of holding a connection open.
  • MCP Apps and an Extensions framework — structured ways to ship richer, optional capabilities on top of the core.
  • Authorization hardening and a formal deprecation policy, which is what a protocol does as it grows up. The Streamable HTTP transport is already gaining routing headers so gateways can authorize an operation without reading the body.

The throughline: the primitives you learned — tools, resources, prompts, the two callbacks — are stable. What’s evolving is the operational envelope around them: how servers scale, run long jobs, and get governed. Build on the primitives with confidence; treat the envelope as something to track.

That’s the series

Twelve posts ago, MCP was an acronym. Now you can write a server in two languages, give its tools real schemas and honest errors, expose data as resources and know-how as prompts, let the server ask the model and the user for help, take it remote over Streamable HTTP, put OAuth in front of it, write the client on the other side, test it in memory, ship it, and assemble all of it into one coherent service — and you know which parts are settled and which are still moving. The protocol turned out to be small, which was always the point: the leverage isn’t in MCP’s surface area, it’s in the fact that the integration you write once now works everywhere that speaks it. Go build the real thing.

Target keyword(s): fastmcp, mcp spec 2026.

Comments