It took Prefect almost 4 years to reach 10,000 GitHub stars.
It took FastMCP about 6 weeks.1
FastMCP is the fastest-growing open-source project I’ve ever been a part of. At this point, factoring in FastMCP 1.0’s inclusion in the official MCP SDK, it’s at the heart of almost every Python MCP server.
But whereas Prefect’s growth came from providing an excellent developer experience in a domain that users traditionally hate, FastMCP’s growth has come from providing an excellent developer experience in a domain that’s exploding in popularity. It’s hard not to be reminded of Patrick O’Shaughnessy’s clear instruction: “Just build something people want.”
But like Prefect, I didn’t build FastMCP because people wanted it. I built it because I wanted it.
When it was introduced last year, the Model Context Protocol (MCP) seemed like a really interesting idea… but it was beyond cumbersome to interact with. FastMCP 1.0 aimed to simplify, dareisay make pleasant, the experience of building MCP servers. It was so effective that Anthropic adopted it as the reference implementation for the official MCP SDK.
As MCP has gotten swept up in hype in the last month, the rough edges around the young protocol have become even more apparent. The core team is trying to rapidly satisfy the community demand for MORE and the naysayer demand for WHY. There’s confusion about what needs to be implemented rather than adopted, for example with auth. There are questions about transports, like whether to use SSE or “streamable” HTTP; both of which seem like overkill for the most common use cases. And there is, of course, the overarching objection: What was wrong with regular old APIs?
MCP is the poster child for tech that’s useful beating tech that’s perfect. I have my own opinions on the protocol (tldr: I like standards, I’m excited about the second-order features that go well beyond request/response, I really wish the reference SDK wasn’t being built by committee) but I’m proud that FastMCP played such an integral role in achieving that approachable utility.
So what’s next?
Historically, FastMCP (1.0) focused on merely providing a pleasant DX over the low-level SDK. With 2.0, we’re providing a full ecosystem of servers, clients, and tooling. It is still hard to stand up a fully authenticated remote MCP server… and it’s even harder to do anything with it. FastMCP 2.0’s headline features like server proxying and composition only scratch the surface of how we can build an integrated, LLM-accessible contextual landscape.
See you at 20k.
Footnotes
-
Well, 6 weeks from re-launching the project as FastMCP 2.0; 6 months from the first 1.0 commit. ⤴️