Sure! There will not be any contention between their roadmaps, in fact FastMCP will continue to evolve somewhat independently of FastMCP Cloud. We'll be announcing our first external maintainer later this week.
Our goal is for FastMCP to be the most full-featured framework for building production-ready MCP servers. FastMCP Cloud is an opinionated way to spin up infrastructure, auth, observability, etc. automatically for those servers. Nonetheless, FastMCP 2.12 (probably releasing this week) will include a completely new auth layer that supports Google, GitHub, WorkOS, and Azure as integrated OAuth providers. It'll also include a new portable deployment configuration that will make it easy to spin up FastMCP servers -- and all their dependencies -- from a declarative JSON file. The objective is to make MCP accessible, whether you want to use our platform or roll your own!
FastMCP author here -- (maybe surprisingly) I agree with many of the observations here.
FastMCP exists because I found the original spec and SDK confusing and complicated. It continues to exist because it turns out there's great utility in curating an agent-native API, especially when so many great dev tools have adopted this client interface.
But the spec is still so young and at such risk of being co-opted by hype (positive and negative). I would invite everyone to participate constructively in improving it.
Lastly: this article is plainly AI generated, as `from mcp import tool` is completely hallucinated. Just some food for thought for the "AI should be able to figure out my complex REST API" crowd that seems well represented here.
I would invite everyone to participate constructively in improving it.
How do you recommend that I participate? I've written a few MCP servers (based on FastMCP - great work!), and contributed one to Anthropic's list. How do I actually participate in maintaining or improving the core MCP spec? I was under the impression that it was being driven by Anthropic.
You're right, that snippet was ai-generated and I forgot to action one of my todos to fix that snippet. This was negligent on my part, and I hope you'll forgive me.
We're fixing that right now, thank you for the correction!
One of the first features we added to FastMCP 2.0 [1] was server composition and proxying (plus some niceties around trying to reuse servers whenever possible) for exactly this reason, so that you can ideally run a single instance of your preferred servers without replicating the setup over every application. In some ways, MCP standardized how agents talk to APIs but introduced a new frontier of lawless distribution! This is something that has to improve.
We're using bird names as a convention for our projects. Which may or may not be the name of the apps. Frogmouth felt more memorable than "mdbrowser" or "markdown-view"
This may just be a personal quirk, but many of these sorts of names to me seem to be one-way memorable. Like, if I see a future reference to "frogmouth" I probably will think "Oh yeah, I've heard of that." I may or may not remember that it's a markdown browser. But if I'm trying to remember "that markdown browser I saw a while ago", I can rarely pull out the name "frogmouth".
Our goal is for FastMCP to be the most full-featured framework for building production-ready MCP servers. FastMCP Cloud is an opinionated way to spin up infrastructure, auth, observability, etc. automatically for those servers. Nonetheless, FastMCP 2.12 (probably releasing this week) will include a completely new auth layer that supports Google, GitHub, WorkOS, and Azure as integrated OAuth providers. It'll also include a new portable deployment configuration that will make it easy to spin up FastMCP servers -- and all their dependencies -- from a declarative JSON file. The objective is to make MCP accessible, whether you want to use our platform or roll your own!