Hi Tip-Sheeters,

​Model Context Protocol is a fast-growing standard for providing data and other context to LLM apps. This is an area that Python is really leading the way, namely FastMCP. According to the FastMCP PyPi page, 70% of all MCP servers (in any programming language) are written with some version of FastMCP.

Yesterday [Feb. 18, 2026], the FastMCP team released FastMCP 3.0 into production with quite a few new features. I had a chance to chat with Jeremiah Lowin, the creator of FastMCP for an exclusive conversation for TIp Sheet readers.

Read to the end to get Jeremiah's advice for the most valuable skill you can develop today.

Jeremiah and I chatted for quite a while, so I'll share highlights across a few issues of the Tip Sheet. (I have edited our conversation for clarity in a few places.)

Part 1 of my conversation with Jeremiah Lowin, FastMCP creator

Ryan: For the newsletter I focus on APIs, data science, AI, and a real emphasis on hands-on technical tips. I like to share with my audience what skills they can be picking up. Starting with MCP, what would you say about the state of MCP today in the industry?

Jeremiah: What is the state of MCP? I think that MCP is playing catch up to its own reputation. I mean that in a good way. The technology is what, a year and a half old if we're generous?

I was on a call the other day with the Linux Foundation for members. [In December, Anthropic donated MCP to the Agentic AI Federation, a directed fund under the Linux foundation.]

They said it's the fastest growing [directed fund] they've ever had. Obviously, it's everywhere. We see it in the downloads, we see it in the popularity, we see it in the use cases. It's just, it's everywhere.

And I have the luxury, I get to spend a lot of time focusing on what's great about it and what I can deliver from it. And so I'm just really excited about MCP.

Ryan: So for someone who is new to MCP and has just heard the acronym, what use cases today are people using MCP for?

Jeremiah: The easiest way to understand MCP if you haven’t looked at it before, is it’s a contract by which new business logic can be bolted onto your agent, without you needing to write that code or own the agent harness. It lets a third party who makes an agent and a third party who makes a piece of software cooperate.

At the end of the day no matter how you think that should happen [through MCP alternatives] it is always better if there is an agreed upon way for you to know how to send information over the wire and how it’s going to come back.

So I think there are two main use cases that we see, and then there's like super long tail.

The most common one by far, I think, is software engineers who are adding capabilities to their coding agents. So for example, there's a Playwright MCP server or a Chrome MCP server for Claude Code that lets it actually look at what it's doing in your browser.

A lot of people use MCP servers to load and read documentation at any time. And interacting with services like GitHub or Linear or Jira or your tool of choice.

The second thing that we see, which I actually think is a lot more interesting and lesser served because it's more proprietary, is we see internal teams using MCP to make functionality or information available throughout their organization.

When we go into organizations now, what we see really frequently is data teams are using MCP to make information available that previously would have been either one super complicated dashboard or 1000 really simple dashboards.

And I think that, like bridging the gap between different teams and their AI cultures and the information and datasets that they have, I think is a really, really, really powerful use of this tool.

Ryan: Which leads us to fast MCP. My journey with it has been when MCP 1.0 was part of the official MCP spec, I did the hello world server with that one. Then I've got an anchor project with a public API that I use. I used FastMCP in the 1.0 release as a wrapper around the API. Then MCP2, I upgraded to that. I launched it on Fast MCP Cloud. And so I've given that in some demos and talks that I've done. And last weekend I went and upgraded to MCP3 and none of the code changed.

Jeremiah: I'm so happy to hear that. It was my nightmare with this big release.

Ryan: Yeah. And then I relaunched my MCP server on Prefect Horizon. So that's sort of my background on it. But tell me the story from your company's perspective and the open source about Fast MCP.

Jeremiah: So let's see, so I will just tell a parallel story to your experience.

So MCP is announced in November 2024. And I see it, and I like, I don't know, I just think this is gonna be a thing.

And I try to build an MCP server, and frankly, I found it very difficult. It's a very low-level SDK. And I was like this should be easier. And I like building tools, I like building frameworks, right? Prefect is a developer tools company. All we do is build tools to help people set up complex systems and hopefully do it with a really pleasant experience. So I decided I want to do that again.

I built FastMCP that weekend.

And so, anyway, so I put it in the world and kind of forget about it, and then I get a note from David Soria Parra at Anthropic, who invented MCP, and he was like: This is really cool. Can we make this part of the official SDK?

So that was honestly just one of the coolest things, the fact that Anthropic noticed and liked this work and wanted to share it with other people.

So we licensed it for inclusion in the SDK, and that was that.

And then time went on and MCP exploded in the spring of the next year, 2025. And I really, I had the same itch that it was growing, it was expanding, there was new functionality in the spec, but the SDK was – correctly I think – just focused on being a low-level SDK and doing that really well.

And so the FastMCP object now was this server builder, the server constructor, but I really had aspirations that one could do more with it and build like a high-level application and have some opinions and do things that you can't get away with in a low-level SDK.

So I dusted it off and we launched FastMCP 2 as a way to capture this whole ecosystem. And that was beautifully timed and MCP went on a hype wave and we were there with it.

And that was very exciting. And it was also very chaotic, right? Every time a new feature came out, a new request came out, we just bolted it in as early as we could.

And so it's amazing that the project didn't collapse under its own weight. And it just took on all this functionality.

And so as we were getting to the end of the year, we stepped back, and I'd really been itching. There was a lot of things I wanted to do that, frankly, were just too much code. to put into FastMCP. It just felt like every major feature started from scratch. There wasn't a reusable architecture just because of how it had evolved.

And so I guess it was December, I stepped back and was like, I think there's an opportunity here to just like really rethink this, but it's going to be a new major version. Even if none of the user-facing stuff changes, the whole backend needs to be rewritten.

And so over the last eight weeks, that's what I've been up to is we step back. We sort of designed, what does a MCP framework look like if you actually design it as opposed to just like build it? And FastMCP3 is that.

So it has all this really cool functionality that's possible because of this architectural redesign. And it does manifest in a lot of user-facing stuff, but it wouldn't have to. it's nice that it does, but the core is what's under the hood. And so that was released.

But the core of it is we can just do all kinds of interesting things, and we architect it in a way where we split up providing MCP functionality from what we call a provider to transforming that functionality.

So, for example, with just a couple lines of code, we could ship a provider that reads tooling from your file system. So there are some people, like a Next.js-style organization, where you just have a bunch of files, each one has a tool in it. That was complicated to support before, because we had a very opinionated belief on what a tool was. But through providers, we can really easily source those things and then reveal them.

We have these transforms, for example, we can do versioning of tools. So we can put some metadata on the tool of what a version is. And then through this transform, we can say, only reveal versions less than two or greater than one.

It's sort of like middleware. So that kind of stuff has been great. We have some new stuff around authorization and authentication. There's a lot in there.

Ryan: So FastMCP, the framework, it's not just the most popular in the Python space. It's number one MCP Server framework in any language?

Jeremiah: I think the statistic that I've heard from Anthropic is that 70% of servers are written in Python. And of those, that's either FastMCP 1, which is part of the official SDK, or that's FastMCP 2, which is what we maintain.

The SDK is downloaded a few million times a day. FastMCP as a standalone project is downloaded 1,000,000 times a day. So it's really this extraordinary reach. There is nothing else. There is nothing else that is used as much. It's just crazy. It's wild.

Ryan: So shift to career and skills here. Big picture, what hand-on skills do you think that data scientists, machine learning engineers, API developers who are in the API space need to be developing right now?

Jeremiah: I think that the most important thing is... When you think about what makes folks in these roles the most effective, in my opinion, it's when they have a clear product mindset. They know the user story, they know what they're trying to satisfy.

For data practitioners, which is my own background, what's the story that we're trying to tell? How much evidence can I deliver against that story for some objective that I'm trying to satisfy?

And I would call that all some variant of product thinking and understanding the user and their objectives. The user could be, it could be your boss who needs an analysis, or it could be an actual customer who needs to use an API, right? But it's an empathy for what that is and delivering against it.

Agents have their own idiosyncratic ways of consuming and accessing information. It's very tempting to think of them as superhuman and like an oracle and perfect in all ways. But that's not the case. They have... advantages and disadvantages.

And so when we're designing MCP servers, you need to think about the product you're building, and you need to think about its consumer, which is an agent.

We call them agent stories sometimes, like a user story for an agent. I think that's the most important skill to develop is an intuition for, like, how do agents interact?

We need a similar intuition for how to interface with agents. And so that's why I think whether you are managing a team of agents. Whether you are writing code paired with them, whether you are designing products for them, having an intuition for how they work optimally I think is the most critical thing to develop right now in order to make sure that our skills are relevant and not replaced.

Ryan: And so what's the tip you would give about developing that intuition?

Jeremiah: I think there's no substitute for interacting with agents directly and literally building this intuition from observing their behavior.

I think the number one thing I would say to someone is if you go into dealing with an agent assuming that it will do right and mistakes are the edge case, then you're wrong. The phrase sometimes we use internally is a “it's an intern, not an oracle”. It's the most capable intern in the world, but it will do what you tell it.

Ryan: In addition to that agent intuition, what technical skills, tools, languages, techniques do you see as high value right now?

Jeremiah: I think actually the most important skill is transitioning to being able to understand whether the agent has written good code or not. And this is complicated, right? Because the agent will definitely write code that works. But is it maintainable code? Is it future proof? Is it DRY in regards to the rest of your code base?

There's all this context that we still are struggling to find a way to imbue those agents with that we as humans pick up pretty organically. I think this is the most important soft skill, which requires some expertise in whatever you're asking it to do.

Ryan: For you personally, what methods have you found in your career for picking up new skills? What techniques work for you?

Jeremiah: I think especially in the last few years being in software, there's no substitute for rolling up your sleeves and just seeing how it works. I think the reason I like building software is because it forces you to understand how it works.

I think metaphorically, I think through my career, I just really like taking things apart and seeing if I can put them back together again. And I've never found a substitute for that.

When I am trying to learn about something, I do kind of read voraciously about it. I try to get as close to the source as possible. So when I was, you know, 20 years ago when I was an ML researcher, just every paper I could find on the neighborhoods that were interesting to me, which in particular was like computational neuroscience. Every paper I would read, I would read folks PhD theses. I would go track them down.

I would go, I think if you really want to learn about something, especially with AI today, anyone can get a surface level education on something real fast.

So if you really want to learn something, I think it requires going and tracking down those primary resources. And I think in software it requires building it and hurting yourself a few times on some sharp edges.

Ryan: Anything else you'd like to share?

Jeremiah: I'm super excited about this. So we talked about 3.0 and its new architecture and some new features that it enables. So a couple weeks ago, as we were getting literally ready to launch the beta, MCP apps came out. I don't know if you've seen it.

Okay, so MCP apps are sort of an evolution of something called MCPUI and also ChatGPT apps. And the idea is how do you embed a full UI inside your chat?

And it's really cool when it works. You're chatting and all of a sudden like a rich interactive experience comes up that looks just like a UI.

An MCP app could let you take that and put [tabular data] in an interactive table viewer that's rendered to you. The LLM never sees it because it's only for you. And now you can use the LLM to interact with information and then you get to interact with it yourself.

In FastMCP 3.1, we're gonna launch not just full support for MCP apps -- that'll actually be in 3.0, -- but we're gonna launch a full Python DSL for building interactive front ends.

We are moving it out of FastMCP. It will be a new open source package for compiling front ends from JSON. And also from a pipeline that lets you go from Python to JSON.

So the library is called prefab, which is because it's prefabricated UIs, but also for Prefect. [Note to readers, Prefect launched the product in February, you can see the GitHub repo here: https://github.com/PrefectHQ/prefab]

And the idea is, the tagline for the moment at least, is that it's a front end that's so easy even a human can use it.

Thanks so much to Jeremiah for making time for the Tip Sheet!

Keep coding,

Ryan Day

👉 https://tips.handsonapibook.com/ -- no spam, just a short email every week.