Sources

## Code Mode Standard MCP has two scaling problems. The entire tool catalog loads into context upfront — with a large server, that's tens of thousands of tokens before the LLM reads a single word of the user's request. And every tool call is a round-trip: the LLM calls a tool, the result flows back through the context window, the LLM reasons about it, calls another tool, and so on. Intermediate results that only exist to feed the next step still burn tokens every time. … ## Under the Hood Heavy imports are now lazy-loaded, meaningfully reducing startup time for servers that don't use every feature. `fastmcp run` and `dev inspector` gain a `-m`/`--module` flag for module-style invocation, `MCPConfigTransport` now correctly persists sessions across tool calls, and `search_result_serializer` gives you a hook to customize how search results are serialized for markdown output. Eight new contributors, and the usual round of fixes.

- The 5 most common manual coding pain points—and how to fix them. - What a Model Context Protocol (MCP) is and why it matters. ... … **1. Authentication boilerplate:** Implementing OAuth flows or token handling for every new service or environment. **2. Data mapping:** Converting API responses into app-friendly structures. This is especially messy when integrating third-party PSPs, PIMs or ERPs. **3. Pagination and filtering:** Writing pagination logic or filtering queries for search endpoints every time from scratch. **4. Validation and error handling:** Inconsistent validations lead to hard-to-debug issues or inconsistent user experiences. **5. Webhook setup:** Manually configuring and testing webhooks for order status, inventory changes, etc., are prone to silent failures. Each of these tasks chips away at developer time and increases the risk of errors that could delay launch.

I was good at this work but was constantly fighting my tools. Every presentation started from scratch because last quarter's deck got lost in someone's email. Every spreadsheet had five versions scattered across shared drives (FINAL, FINAL_v2, FINAL_ACTUALLY_FINAL). Strategic documents just sat there as frozen artifacts. No way to see how we got there, why we decided anything. The real pain was context switching and consistency. I'd spend my morning in Salesforce tracking progress, then export to Excel for analysis, copy insights into Word for documentation, paste tables into PowerPoint for presentations, upload everything to SharePoint for "version control," and then email the whole mess to stakeholders with links going every which way. Each tool was an island that required its own mental map to get around. The integration & context layer was me, manually copying and pasting, trying to keep it all synchronized in my head. Then I learned how to code. The more code I wrote, the more I questioned everything about knowledge work. Why don't we version control strategic decisions? Why is copy-paste our integration layer? How much context am I losing jumping between platforms all day, all week, all month? … This isn't anyone's fault. These tools were built when documents were the atomic unit of knowledge work. They've been incrementally improved, but the fundamental model stayed the same. Create isolated artifacts, store them in silos, manually integrate. To further complicate things, countless other tools promised to solve the context problem but most just add another layer of complexity. You're often not solving the context problem. Just adding to it.

The Model Context Protocol (MCP) is rapidly becoming a standard for providing context and tooling for LLM applications. However, implementing an MCP server typically involves substantial boilerplate for setup, protocol handling and error management. **FastMCP** is a Python framework that simplifies this process by abstracting away protocol complexity and allowing developers to define MCP resources and tooling through intuitive Python decorators. This abstraction enables teams to focus on business logic, resulting in cleaner, more maintainable MCP implementations.

What it really does, in plain English, is give developers a way to build and manage systems where AI models can access and use tools or data sources dynamically. For example, if you want your AI to query a database, call an API, or even trigger a workflow, FastMCP provides the scaffolding to make that happen smoothly. The core issue it’s trying to solve is the fragmentation and complexity involved in connecting LLMs with external resources — often, developers end up cobbling together custom APIs, middleware, or rely on ad-hoc solutions. … ## FastMCP 3.0 Pricing: Is It Worth It? ... No clear usage limits or feature restrictions are specified, which makes it hard to gauge its sufficiency for serious projects.| ... … ### What Could Be Better - **Steep learning curve:** Despite the promise of simplicity, the architecture's depth can be overwhelming—especially for newcomers trying to understand components, transforms, and providers all at once. - **Limited documentation on core concepts:** While the documentation covers setup and basic features, some advanced features like proxying, filtering, or middleware are only briefly touched upon, which could leave users scratching their heads. - **Opaque pricing and hosting details:** The lack of explicit pricing info or usage limits makes it hard to plan budgets or assess whether it fits your scale—this could be a dealbreaker if you're trying to estimate costs upfront. - **Relies heavily on Prefect ecosystem:** If you prefer self-hosted or alternative hosting options, this could be restrictive, as the platform seems tightly integrated with Prefect Horizon. - **Potential overkill for simple use cases:** For small projects or straightforward tool hosting, the complexity and features might be more than you need, making it feel bloated or unnecessarily complicated. … ### OpenAI GPT API + Custom Backend Using OpenAI’s API directly with a custom backend gives you flexibility to design your own logic but leaves you responsible for building features like context management, security, and scaling. ... But it requires more manual work for features like versioning, auth, and observability, which FastMCP provides out of the box. Choose FastAPI if you need a lightweight, highly customizable API server and are willing to handle the additional complexity yourself. ... …

## FastMCP 2.14.6: $Ref Dead Redemption v2.14.4 backported `dereference_refs()` but never wired it into the tool schema pipeline — `$ref` and `$defs` were still sent to MCP clients. Now fixed: schemas are fully inlined before reaching clients. ​ ... Fixes a memory leak in the memory:// docket broker where cancelled tasks accumulated instead of being cleaned up. Bumps pydocket to ≥0.17.2. ​ ... Fixes a fresh install bug where the packaging library was missing as a direct dependency, plus backports $ref dereferencing in tool schemas and a task capabilities location fix. ​ FastMCP 2.14.3 ... ## FastMCP 2.14.3: Time After Timeout Sometimes five seconds just isn’t enough. This release fixes an HTTP transport bug that was cutting connections short, along with OAuth and Redis fixes, better ASGI support, and CLI update notifications so you never miss a beat. ​ FastMCP 2.14.2 ... December 31, 2025 ... FastMCP 2.14.2 brings a wave of community contributions safely into the 2.x line. A variety of important fixes backported from 3.0 work improve OpenAPI 3.1 compatibility, MCP spec compliance for output schemas and elicitation, and correct a subtle base_url fallback issue. The CLI now gently reminds you that FastMCP 3.0 is on the horizon. … ... FastMCP 2.14 begins adopting the MCP 2025-11-25 specification, introducing protocol-native background tasks that enable long-running operations to report progress without blocking clients.⏳ **Background Tasks (SEP-1686)** let you add `task=True` to any async tool decorator. Powered by Docket for enterprise task scheduling—in-memory backends work out-of-the-box, Redis enables persistence and horizontal scaling. … ## FastMCP 2.13.1: Heavy Meta Introduces meta parameter support for `ToolResult`, enabling tools to return supplementary metadata alongside results for patterns like OpenAI’s Apps SDK.🏷️ **Meta parameters** let tools return supplementary metadata alongside results.🔐 **New auth providers** for OCI and Supabase, plus custom token verifiers with DebugTokenVerifier for development.🔒 **Security fixes** for CVE-2025-61920 and safer Cursor deeplink URL validation on Windows. … The new consent screen prevents confused deputy and authorization bypass attacks discovered in earlier versions, while the OAuth proxy now issues its own tokens with automatic key derivation. RFC 7662 token introspection support enables enterprise auth flows, and path prefix mounting enables OAuth-protected servers to integrate into existing web applications. FastMCP now supports out-of-the-box authentication with WorkOS and AuthKit, GitHub, Google, Azure (Entra ID), AWS Cognito, Auth0, Descope, Scalekit, JWTs, and RFC 7662 token introspection. … ## FastMCP 2.12.5: Safety Pin Pins MCP SDK version below 1.17 to ensure the `.well-known` payload appears in the expected location when using FastMCP auth providers with composite applications. ​ FastMCP 2.12.4 ... ## FastMCP 2.12.2: Perchance to Stream Hotfix for streamable-http transport validation in fastmcp.json configuration files, resolving a parsing error when CLI arguments were merged against the configuration spec. ​ FastMCP 2.12.1 ... FastMCP 2.10 achieves full compliance with the 6/18/2025 MCP specification update, introducing powerful new communication patterns.💬 **Elicitation Support** enables dynamic server-client communication and “human-in-the-loop” workflows, allowing servers to request additional information during execution.📊 **Output Schemas** provide structured outputs for tools, making results more predictable and easier to parse programmatically.

Jeremiah Lowin breaks down why most MCP servers miss the mark and what to do about it. As the creator of FastMCP, Jeremiah has seen every way people build MCP servers. Most of them aren't great. But here's the thing - it's not because people are bad at building. It's because we're designing for the wrong user. This talk is about agentic product design. Agents aren't humans. They're expensive at discovery, slow at iteration, and limited on context. So why are we building interfaces for them like they're just magical humans who can handle anything? Recorded at AI Engineer Code Summit 2025. ... … It enumerates every single tool and every single {ts:391} description on that server. So discovery is actually really expensive for agents. It consumes a lot of tokens. Um next {ts:398} iteration. Same idea. If you're a human developer and you're writing code against an API, you can iterate really … There's a big asterisk on that because {ts:574} client implementations in the MCP space right now are not amazing and they do some things that are themselves not {ts:579} compliant with the MCP spec. Maybe at the end we'll get into that. It's not directly relevant to now except {ts:586} that all we can do is try to build the best servers we can subject to the limitations of the clients that will use … {ts:938} the middle because they can do it but it's expensive and slow and annoying and hard to debug and stochcastic. And so if {ts:944} you can avoid that, please do. If you can't, there are times when you don't know the algorithm and you don't know {ts:949} how to write the code and it's not programmatic. … {ts:1167} but it's still going to be hard. There was until very recently there may still be a bug in maybe it's not a bug because {ts:1175} no one seems to fix it but in cloud desktop all um all structured arguments like object arguments would be sent as a {ts:1184} string and this created a real problem um because we do not want to support automatic string conversion to object … It gets what it sees as information about the fact that it didn't uh succeed in {ts:1466} what it was attempting to do. And so if you just allow Python in in fastmcp's case or whatever your tool of choice is {ts:1473} to raise for example an empty value error or a cryptic MCP error with an integer code that's the information that … {ts:1492} interesting strategies that I don't want to wholeheartedly endorse but I will mention where for example if you do have {ts:1497} a complex API because you can't get away from that. Then instead of documenting every possibility in the dock string {ts:1505} that that documents the entire tool you might actually document how to recover from the most common failures. … Who cares? One of the problems is that there are clients that are not compliant with the spec. Cloud Desktop {ts:1860} is one of them. I've mentioned it a few times. I have a history with Cloud Desktop. Um Cloud Desktop hashes all of {ts:1866} the tools it receives on the first contact and puts them in a SQLite database and it doesn't care what you

38:12 Q&A starts 38:53 Per-tool authorization 39:09 Unmounting servers 40:58 FastMCP in Frontier 42:10 Registry support 44:04 Code review workflow & AI in the process 48:08 Prefab native app support 50:44 Code mode & sandboxing with Monty 53:16 A2A protocol thoughts 55:29 MCP apps & external URLs 57:17 Background tasks & closing … ... {ts:395} is that incremental features took longer and longer and longer to add on because the surface area of worrying about {ts:402} interrupting or disrupting or compliance with other features in the system. It's a framework. Everything has to work {ts:409} together. And if everything shares its own code path, well, all of a sudden, introducing a new code path and trying … {ts:465} And I was like, "Oh, this is great. ... … So, mounting servers in open API, which is the {ts:1204} feature that we love to hate. Um uh so many people are building MCP servers by converting open API specs uh and then {ts:1212} they end up with a really bad MCP server because it's a different type of API uh and then they blame MCP and that gets {ts:1219} really frustrating after a while and so I had to write this blog post telling people to stop using this feature. Uh {ts:1224} nobody has stopped using it. They use it a lot. um it's disproportionately um issues opened and enhancements requested {ts:1231} and so happily the open API converter is now implemented as a provider which again lets it be compatible with

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.

It’s the go-to pattern for adding cross-cutting concerns like authentication, logging, or caching without rewriting your core application logic. Until today, when developers asked how to add middleware to their MCP server, the obvious answer seemed to be wrapping their server with traditional ASGI middleware. Unfortunately, that approach has two critical flaws: 1. It only works for web-based transports like streamable-HTTP and SSE. Until very recently, most major clients only supported the local STDIO transport, making this a non-starter for many. 2. More importantly, it forces you to parse the MCP’s low-level JSON-RPC messages yourself. All the hard work FastMCP does to give you clean, high-level Tool and Resource objects is lost. You’re left trying to reconstruct meaning from a sea of protocol noise. This is a lot of work for a very limited set of outcomes. So, we went back to the drawing board and embraced a core FastMCP principle: **focus on the developer’s intent, not the protocol’s complexity.** ... FastMCP 2.9 is a huge release, and it also includes one highly-requested feature: **server-side type conversion for prompt arguments.** The MCP spec requires all prompt arguments to be strings. This has been a persistent developer pain point. Why? Because the Python function that generates those prompts often needs structured data to perform business logic, such as a list of IDs to look up, a dictionary of configuration, or some filter criteria. This has forced developers to litter their prompt logic with `json.loads()` and pray that the agent provides a compatible input. … An MCP client would call this with `{"user_ids": "[1, 2, 3]", "analysis_type": "performance"}`, but the MCP server would receive a clean `list` and `str`. It’s a small change that removes a huge amount of friction, especially when prompts are doing more than just string interpolation. FastMCP’s implementation of this feature is fully MCP spec-compliant, but because there is no *formal* way to describe the expected JSON Schema format of a prompt argument, it’s possible that some clients will choose to ignore it. As with all agentic users, performance will depend on clarity of your instructions.

## Security blind spots of MCP servers The power of MCP is also its primary security challenge. A server announces its available tools and resources to any connected client, and a naive implementation exposes every single tool to every single user. This creates a massive security risk, as tools that can delete data or trigger sensitive operations become available to anyone, regardless of their role or permissions. These tools can often bypass the rigorous security models built around traditional APIs. This is why you need fine-grained authorization for any production FastMCP server. When an AI agent acts on a user's behalf, it must be subject to that user's permissions. Without it, low-privilege users could instruct an agent to use highly sensitive tools, leading to a significant security vulnerability. When an agent inevitably tries to use a tool it doesn't have access to, the action fails, making the agent appear broken and eroding user trust. The security risks are not just theoretical. What I have observed from speaking with engineering teams is that they often hardcode authorization logic using complex if/else statements within the MCP server itself. This approach is brittle, error-prone, and makes adding new tools or changing business rules a slow and expensive engineering task. Research from security firms highlights the real-world dangers, as one report from TrendMicro stated, "We found 492 MCP servers with no client authentication or traffic encryption...Successful attacks against these servers lead to data breaches, leaking sensitive information such as company proprietary information and customer details."

- **Built-in debugging accelerates development** - MCP Inspector provides web interface for testing tools, resources, and prompts before deployment ... |**Setup Complexity**|Minimal (decorators)|High (manual protocol)|Medium (type definitions)| |**Development Time**|1-2 hours|8-12 hours|4-6 hours| |**Built-in Debugging**|✅ MCP Inspector|❌ Manual testing|✅ Basic tools| |**Error Handling**|✅ Automatic wrapping|❌ Manual implementation|✅ TypeScript safety| |**Documentation**|✅ Comprehensive|❌ Limited examples|✅ Good coverage| ... Design your MCP server to handle production workloads effectively: **Resource management:** - **Memory limits**: Implement file size restrictions and memory monitoring - **Concurrent processing**: Use async/await for handling multiple requests - **Rate limiting**: Prevent abuse with request throttling - **Health checks**: Monitor server status and resource usage … ### How do I fix MCP server connection issues? Connection problems typically stem from configuration errors or missing dependencies. Verify your MCP configuration file has correct commands and absolute paths. Test independently using `mcp dev your_server.py` before troubleshooting host integration. Check environment variables and dependency installations are complete.