FastMCP with Adam Azzam and Jeremiah Lowin

What It Covers

Jeremiah Lowin and Adam Azzam, founder/CEO and VP of Product at Prefect, trace FastMCP's evolution from a weekend side project into a framework downloaded 2 million times daily. They cover the three pillars of servers, clients, and apps, the FastMCP 3.0 rearchitecture, and the freshly shipped code mode feature built on Pydantic's Monty sandbox runtime.

Key Questions Answered

• •Decorator-first server design: FastMCP's core innovation mirrors FastAPI's pattern — a single `@mcp.tool` decorator registers any Python function as an MCP tool, replacing manual dispatch logic against raw JSON-RPC. This one abstraction drove initial viral adoption and remains the framework's foundation. Developers already familiar with FastAPI or Prefect's decorator patterns can build a functional MCP server in minutes without touching the low-level SDK.
• •Internal vs. external MCP use cases: Over 80% of FastMCP's real-world deployments are internal enterprise servers — not public-facing tools. Companies like Databricks, Snowflake, and MLflow use it to expose governed, identity-aware toolsets to employees. Internal deployments justify MCP over CLIs because they require stateful, bidirectional communication, role-based tool visibility, and tight contracts — none of which REST or CLI patterns handle cleanly without reinventing a protocol.
• •Rearchitecting before scaling features: FastMCP 3.0 was a deliberate ground-up redesign triggered by bolted-on technical debt across 2.x. The key new primitive is "transforms," which lets new capabilities slot into one file rather than spawning independent code paths. The payoff was immediate: code mode, a transformative feature, shipped as a net addition of roughly 200 lines of core code rather than the estimated 5,000–10,000 lines it would have required on the 2.x architecture.
• •Code mode shifts execution from client to server: Traditional MCP clients call tools serially, producing quadratic token growth per conversation turn. Code mode exposes two tools — search over a tool catalog and a code executor — letting the LLM author a full program against the server's toolset in one pass. Execution happens inside a secure sandbox (Pydantic's Monty runtime locally, or Modal/Daytona/Cloudflare remotely), removing dependency on client-side support and making parallel tool execution available across any MCP client.
• •MCP apps address the markdown rendering problem: When an MCP server returns 10,000 database rows, current LLM clients render the result as a markdown list — a poor user experience that also bloats the context window. FastMCP's apps pillar, paired with an open-source DSL called Prefab, lets server authors return typed UI components (bar charts, data tables, forms compiled from Pydantic models) directly from tool responses. Supported clients like VS Code, Goose, and Claude Code then render these components natively rather than as text.
• •Client quality is the bottleneck, not the protocol: Most MCP adoption problems trace to clients that only implement tool calling and ignore resources, prompts, and tasks. When evaluating MCP clients, prioritize ones that support the full spec: Claude Code uses BM25 search over the tool catalog rather than stuffing all tools into the context window, VS Code and Goose support the complete range of MCP primitives. Server authors should test against multiple clients because identical server code produces wildly different agent behavior depending on client implementation quality.