Recap: what MCP is and why you should care about it
MCP solves a simple problem: it allows AI models to communicate with external systems and tools in a standardized way. The TL;DR from my first post:
The Model Context Protocol helps models like Claude talk and work with external systems in a standardized way.
AI models today struggle mightily with accessing external data from the tools you use every day
The Model Context Protocol is a standardized way for AI models to talk to external systems like databases, Google Maps, and more
Via MCP, models can pull data from these systems, or even take action in them (like sending an email)
Providers need to build MCP servers that allow models to integrate with their systems
Outside of new OpenAI and Google models coming online, for the most part, the “client” part of the equation – these are the models that can hook into MCP – hasn’t changed since MCP was released. It is the server side of the equation that has seen the most action, in the form of companies of all shapes and sizes building and releasing their own MCP servers. They do this because they want more people using AI models to be able to use their tools via those AI models.
This is actually how MCP came to be in the first place. It wasn’t part of some big company wide strategy. The creators of MCP – David Parra and Justin Spahr-Summers (no relation) – were engineers at Anthropic working on internal developer tooling, and started riffing on an idea to make Claude more useful for their team. Everyone was getting a ton of value out of Claude, but it was kind of a closed system; it couldn’t “talk” to any of their other tools.
So many of the tools that developers use today integrate deeply with the rest of their ecosystem. Just think about the IDE (integrated development environment), where developers write their code. The most popular one – Microsoft’s VSCode – has an incredibly rich plugin ecosystem. You can essentially integrate it with anything, pulling in data and triggering action in any other tools in your stack.
But Claude wasn’t like that. If you wanted to get data in there, you needed to include it in your prompt. And it certainly couldn’t just do something in another tool like GitHub or Linear. So they came up with this idea for a standard way for models to communicate with external tools. The thing that eventually became MCP was a “side project”-esque internal developer tool at Anthropic, not some strategic masterstroke by the leadership team.
This little bit of history is extremely important, because it explains exactly why the MCP standard ended up being so difficult to build with, and why to this day there’s only a tiny 4-5 person team at Anthropic supporting it; despite how popular and important it has become. It was never intended to be a universal, widely adopted standard. It was a weekend project!
Why it’s so hard to build an MCP server today
Just based on the sheer number of companies releasing and improving their MCP servers every week, you’d assume that doing so is a breeze. But you’d be wrong!
Building an MCP server is very difficult today because the specification is highly complex, and reinvents a number of things that most engineers thought were established already. So many things were experimental and unresolved when it came out; just to name one, at release you couldn’t use an MCP server in the cloud. You had to download it to your local machine and run it there (incredible security risk).
The most important reason that MCP was hard to work with was that it was designed to be very low level, which is generally an important idea in software engineering. It essentially means that you have to do a lot of things – perhaps too many things – to get a basic server up and running.
To better understand what it means for software to be low level, I went through my extensive analogy rolodex and came up with a few ideas. I hope they’re to your liking.
- If you’re cooking something that needs a metric fuck ton of garlic, you might opt to buy the pre-peeled cloves from the store. You could peel your own, but that would be annoying.
- Most cars today come with automatic transmissions. You could shift on your own, but that would be annoying.
- I love my Unimatic U-4. The crazy Italians who built it could have made their own automatic movement, but that would be annoying. So they sourced a Seiko NH35A instead.
This is essentially what’s going on with the MCP protocol. When I say it’s low level I mean that it is barebones. It doesn’t do any of the work for you. You need to build your server totally from scratch, from coding every small piece of logic to manually parsing every piece of data that you get from a model. And the kicker is that most of this work is identical from company to company; there’s no good reason you should have to do it from scratch.
I mentioned that something being low level vs. high level is a general software concept, and another area where this idea applies is building web servers. Today pretty much everyone uses a web framework – like NextJS, Django, or Rails – to build their apps that you access on the web. The framework takes care of all of these low level things for you, like handling API requests, creating different pages, things like that. That way, developers can just focus on writing the code that’s custom to their app; not run of the mill stuff that’s mostly the same for everyone.
And yet with MCP, you have to do all of these things yourself…even though there’s no particularly good reason to.
I really should mention that being low level is not a wrong design decision. Many of the most critical and beloved developer frameworks out there are incredibly low level. It totally depends on the context and the workflow that the tool fits into. Sometimes, for some tasks, you need things to be low level so you can customize them. But for MCP, it mostly just bogged people down with writing server code, instead of the stuff that actually mattered for the model and their app.
[My friends at Knock were one of the first companies to release an MCP server. They ran into a few of these issues:]
The FastMCP story
Jeremiah Lowin (engineer, Prefect CEO, affectionately referred to as “J-lo”) tried out MCP basically as soon as it came out, which was on a Thursday. He quickly found that despite how excited he was to use it, he was struggling because of how arcane and low level the spec was; he spent hours and could barely figure it out.
So partially to teach himself how the low level server components worked – and with a bit of a spidey sense that people might want something like this in the future – he built the first version of FastMCP over the weekend. The idea is simple: it does all of the low level stuff for you. FastMCP takes care of all of the run of the mill, boilerplate work that MCP does not – so you can focus on writing the business logic that actually matters to your MCP server.
Anyway, Jeremiah spent so much time building FastMCP that he had no time to build an actual MCP server, shelved the project, and moved on with his life. Two weeks later though, he got a call from the Anthropic engineers that built MCP. They found FastMCP, immediately loved it, and wanted to figure out how to integrate it into the OG MCP to make it a default part of the stack (!). It’s now an official part of Anthropic’s MCP SDK (check out their quickstart here).
Since then, Anthropic has put a lot of time into maintaining the lower level SDK (OG MCP), which has created even more of an opportunity for complementary, higher-level tooling. So Jeremiah decided to release FastMCP 2.0, a significantly improved version based on dozens of conversations with people building MCP servers and what they needed. It already has 17K GitHub stars and an active community of engineers maintaining and building it.
FastMCP 101
So what does FastMCP look like, exactly? Instead of having to write all of this low level server stuff, you can just write the functions that you want models to be able to call, and “decorate” them with FastMCP language. Let’s say you’re Gmail, and you’re building an MCP server. You want a user to be able to search via a model; they prompt something like “show me all emails from last year” and they get back, well, all of their emails from last year.
You already have an API on your backend that searches through emails based on a keyword, dates, times, etc. You want to connect it to a model, and make sure when a user prompts the model with something like “search for me” the model knows to use this API in particular (not, say, your API for deleting an email. Models are dumb). Your function might look something like this:
def searchEmail(date_range):
emails = search(date_range)
return emails
With FastMCP, all you need to do is wrap it up with the little @mcp.tool :
@mcp.tool
def searchEmail(date_range):
emails = search(date_range)
return emails
And then optionally, tell the model when to use this:
mcp_with_instructions = FastMCP(
name="GmailAssistant",
instructions="""
This server provides the ability to interact with email.
Call searchEmail() to search through emails.
""",
)
No boilerplate required.
This is the most simple possible example. And indeed, many MCP servers out there are incredibly simple; they are just a wrapper that exposes a company’s APIs to some models. But in the future, these things are going to get radically more interactive and complex, in a good way. There are so many more things you can do with FastMCP:
The longer-term vision here is turning a conversation with an LLM into an interactive one, not just a one-sided “get me data from this server” thing.
The fastest (sorry) way to get started with FastMCP (and ergo, the fastest way to build an MCP server) is with the newly released FastMCP Cloud, built and maintained by the team at Prefect. It takes care of all of the infrastructure of an MCP server for you, plus things like authentication, scaling, analytics, and other nice things. All you need to do is write your business logic, and they take care of the rest. You can get started for free here.
