www.jlowin.dev
FastMCP 2.13: Storage, Security, and Scale - Mostly Harmless
Excerpt
The massive adoption of the OAuth proxy meant the community immediately started battle-testing our auth implementation in real-world scenarios. We learned our original Azure provider only worked in the narrowest of cases; intrepid users helped us build a far more robust version. Others contributed a variety of new providers, with the result being that FastMCP now supports out-of-the-box authentication with: … More critically, I owe a huge thanks to MCP Core Committee member **Den Delimarsky** for responsibly disclosing two nuanced, MCP-specific vulnerabilities: a confused deputy attack and a related token security boundary issue. The fixes required some novel solutions, including having the proxy issue its own tokens and implementing a new consent screen for explicit client approval. Our OAuth implementation is now hardened, spec-compliant, and thanks to the community’s scrutiny, ready for production. … - **Response Caching:** The new `ResponseCachingMiddleware` provides an instant performance win for expensive, repeated tool and resource calls. - **Server Lifespans:** We fixed a long-standing point of confusion in the MCP SDK. `lifespan` now correctly refers to the *server* lifecycle (for things like DB connections), not the client session. This is a breaking change, but it’s the correct one.
Source URL
https://www.jlowin.dev/blog/fastmcp-2-13Related Pain Points
Rushed implementations create security vulnerabilities
8Poor OAuth 2.0 developer experience and documentation gaps lead teams to implement insecure workarounds under time pressure, creating security holes in production systems.
MCP protocol confusion about server lifecycle vs client session lifecycle
5The `lifespan` parameter in MCP SDK was ambiguous and commonly misunderstood—developers thought it referred to client sessions when it should refer to server lifecycle (e.g., database connections), causing initialization and cleanup logic to run incorrectly.