We chose FastMCP because it treats MCP servers like FastAPI applications.
Decorator-based DX: Instead of writing verbose class-based boilerplate, we just use
@mcp.tool(). It feels exactly like writing a FastAPI route.
Pydantic Native: Since we heavily use Pydantic for data validation (SERP results, GSC data), FastMCP's native integration saved us hours of conversion work.
Built-in Image Support: FastMCP makes it incredibly easy to return multimodal responses (images + text), which is crucial for our "Site Health Check" features that visualize data.
SSE out-of-the-box: Connecting to Claude Desktop requires a robust Server-Sent Events implementation. FastMCP handles the handshake, keep-alive, and transport details automatically.
It's the "FastAPI moment" for the MCP ecosystem.
From @jlowin :
FastMCP 3.0 is the platform MCP deserves in 2026, built to be as durable as it is future-proof:
@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? 🔥
@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.
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)?
@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!
Can you tell a little bit more about what you do in version 3, please? How does it differ from 2?
@anton_tishchenko we have a post that covers all the new features here: https://www.jlowin.dev/blog/fastmcp-3-whats-new
@jlowin Thank you!
love the shift to stateful context apps over just dumb tool servers. does this replace the need for LangGraph in simpler agents?
The integrated tool experience is so seamless—it’s like a universal adapter that lets you plug in all kinds of data sources and use them right away. But it’d be even easier for newbies to build apps if there were pre-built templates for common use cases, like an automatic weekly report generator.
Real-time hot reloading and status tracking are super thoughtful! You don’t have to restart the service when modifying code—it’s like having an assistant refreshing things in sync. That said, troubleshooting would be much more intuitive if the task log interface was visualized on a timeline.