FastMCP 3.0
The fast, Pythonic way to build MCP servers and clients
Start new thread
Chris Messina

FastMCP 3.0 - The fast, Pythonic way to build MCP servers and clients

by
Raycast
•
FastMCP 3.0 is a framework for building smarter AI context apps, not just tool servers. Pull tools and data from anywhere, reshape them, control access, track state, and run long tasks — with hot reload, versioning, and observability built in for production use.

Add a comment

Replies

Best
Chris Messina
Hunter
📌

From @jlowin :

FastMCP 3.0 is the platform MCP deserves in 2026, built to be as durable as it is future-proof:

We are moving beyond simple “tool servers.” We are entering the era of Context Applications—rich, adaptive systems that manage the information flow to agents.

The real challenge was never implementing the protocol. It’s delivering the right information at the right time. FastMCP 3 is built for that:

  • Source components from anywhere.

  • Compose and transform them freely.

  • Personalize what each user sees.

  • Track state across sessions.

  • Control access at every level.

  • Run long operations in the background.

  • Version your APIs.

  • Observe everything.

It’s time to move fast and make things.

Elior

Congrats on the launch — love how FastMCP is pushing MCP beyond “tool servers” into real context apps with state, access control, and observability built in.

Love the "context applications" framing - MCP isn’t hard, relevance is.
Curious what you’ve seen as the biggest source of pain in practice: state across sessions, access control, or debugging/observability once you have multiple sources in the loop?
Also - do you have an opinionated default for tracing tool calls end-to-end (so people don’t live in logs)?

Jeremiah Lowin
Maker

@dmitry_petrakov I think authentication followed by more granular access control has been a major blocker. State across sessions is more of an enabler than blocker; and observability is something we just always want to improve!

Van de Vouchy
Hey Chris, that line about the real challenge being delivering the right info at the right time, not implementing the protocol, is a good reframe. Was there a specific project where you had MCP working technically but the agent still wasn’t getting what it needed when it needed it?
Jeremiah Lowin
Maker

@vouchy We see this in practice all the time -- common gotchas are tightly coupled tools (either that need to be called in sequence, or with correlated information) that the agent doesn't call correctly. Another is simply having too many tools with too many descriptions; choice paralysis is real.

Asad Iqbal

We've been adopters of FastMCP since the early days at Noodle Seed! - Super excited to see the launch of version 3.0!

Jeremiah Lowin
Maker

@asadatnoodle Thanks!

Mykyta Semenov 🇺🇦🇳🇱

Sounds interesting. We’re actually building an AI app in Python, I’ll show your product to the team…

Abdul Rehman

Context drift is what kills most agents. It is a clean way to control what agents see instead of flooding them.

Anton Tishchenko

Can you tell a little bit more about what you do in version 3, please? How does it differ from 2?

Jeremiah Lowin
Maker

@anton_tishchenko we have a post that covers all the new features here: https://www.jlowin.dev/blog/fastmcp-3-whats-new

Anton Tishchenko

@jlowin Thank you!

Samet Sezer

love the shift to stateful context apps over just dumb tool servers. does this replace the need for LangGraph in simpler agents?

Ryan Thill

@jlowin jlowin — “context applications” (state + ACL + long tasks + observability) is exactly where MCP gets painful at scale: multi-source fan-out + stale context + non-idempotent tool runs.

Best-practice: treat every tool call as a versioned contract (Pydantic schemas + semver), persist state as an event log (so you can replay/debug), and add distributed tracing with correlation IDs across sources/steps.

Q: is state storage pluggable (Redis/Postgres) with resumable long-jobs, and do you support per-user ACL down to field-level redaction in composed contexts? 🔥

Jeremiah Lowin
Maker

@ryan_thill state storage is pluggable, yes. The built-in auth hooks are registered at the tool or server level, so applying it at the field level would require leveraging the auth context yourself to modify the result. You could do this either as a custom wrapper for your tools, or a custom middleware.

12
Next
Last