Pod Insights Software Engineering Daily FastMCP with Adam Azzam and Jeremiah Lowin About this episode The Model Context Protocol, or MCP, gives developers a common way to expose tools, data, and capabilities to large language models, and it has quickly become an important standard in agentic AI. FastMCP is an open source project stewarded by the team at Prefect https://www.prefect.io/, which is an orchestration platform for AI and data workflows. The FastMCP project builds on MCP to provide high-level, ergonomic abstractions for Python developers to rapidly build and deploy MCP servers and applications.
Jeremiah Lowin https://x.com/jlowin is the founder and CEO of Prefect, and Adam Azzam https://x.com/AAAzzam is the VP of Product at the company. In this episode, Jeremiah and Adam join Gregor Vand to discuss the origin story of FastMCP, the three pillars of the framework, the architectural decisions behind FastMCP 3.0, and much more.
https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/11/Gregor-Vand.jpegGregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance and general software engineering companies. He is based in Singapore and can be found via his profile at vand.hk or on LinkedIn.
Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/03/SED1920-FastMCP.txt
Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected]
The post FastMCP with Adam Azzam and Jeremiah Lowin https://softwareengineeringdaily.com/podcasts/fastmcp-with-adam-azzam-and-jeremiah-lowin/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.
Transcript 13,154 words · 4 speakers
0:00 Speaker 00 The Model Context Protocol, or MCP, gives developers a common way to expose tools, data, and capabilities to large language models, and it has quickly become an important standard in agentic AI. FAST MCP is an open source project stewarded by the team at Prefect, which is an orchestration platform for AI and data workflows. The FAST MCP project builds on MCP to provide high-level ergonomic abstractions for Python developers to rapidly build and deploy MCP servers and applications. Jeremiah Lowin is the founder and CEO of Prefect, and Adam Azam is the VP of Product at the company. In this episode, Jeremiah and Adam join Gregor Van to discuss the origin story of FAST
0:45 Speaker 00 MCP, the three pillars of the framework, the architectural decisions behind FAST MCP 3.0, and much more. Gregor Van is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk or on LinkedIn.
1:23 Speaker 01 Hello and welcome to Software Engineering Daily. Today, we have two guests, which is always exciting. So today, we've got Jeremiah Lowin and Adam Azam. Thank you for joining us, guys.
1:33 Speaker 02 Thank you so much for having us.
1:35 Speaker 01 Yeah, so we're here to talk all things FAST MCP, which I'm sure a lot of our listener base know about at least, but maybe a good chunk have used as well. So we're going to get into where it's come from, what it's all about. As usual, we do like to just hear the backstories of who we're talking to. So you guys can fight amongst yourselves, who wants to go first, but yeah, where did you both come from in terms of careers and getting to, I guess, founding SMCP?
2:05 Speaker 02 Sure. This is Jeremiah. Spent most of my career actually in buy-side finance in some risk or technology or applied statistics or machine learning kind of field. Data scientist is probably the best career heading for what I was doing there. And as a result, I became obsessed with building tools for people. Tools for my colleagues, tools for folks across the firm, different objectives, whatever it was, I just became obsessed with building tools and Python became a real home for building those tools and also automating those tools. I like to joke, it's not really a joke, but I had unlimited budget for software and zero budget for headcount. And so this is, you know, this is 20 years ago. So it was really, how do we find more hours in the day through technology? And so through some circuitous paths, that led me to be part of the original airflow
2:49 Speaker 02 team, which I think popularized a lot of code-first automation, a lot of folks' eyes. And then, of course, I started Prefect in 2018 to build a more data science-native, more Pythonic automation framework. And so for the last eight years, I've been the CEO of Prefect. And for most of that time, our product focus has been almost entirely on automation and orchestration of enterprise workflows. And that's been a lot of fun. And then about a year and a half ago, when MCP was announced, I thought that that might be the link that we had been really looking for of how to bridge the gap between programmatic workflows and agentic workflows. And I got really involved and wrote the first version of Fast MCP. And I'm sure we'll go more into the history of that in a moment. But Fast MCP took off in a way that I don't think we could have quite anticipated.
3:34 Speaker 02 And Adam and I have been working together for a few years now. And so we sort of stuck a flag in the ground and made this a new pillar of Prefect's business. And it's been an incredible ride. I'm sure we'll explore a lot of it today.
3:45 Speaker 01 Nice, awesome. So yeah, Adam, what about you?
3:48 Speaker 03 So I was an academic. I did a PhD in math. In an alternate universe, I was off being a math professor, doing partial differential equations. I got bit by a data science and ML bug in my last year, two years of grad school. So went into data science and My first job in data science was basically how do you help folks get jobs? So how do you help match them to recruiters? How do you help them like? How do you recommend interview preparation material to them to improve their outcomes in interviews? So worked in basically data science for improving job seeker outcomes for a bit. Founded a startup around that really when L L M's were they were they're more like small language models at the time.
4:32 Speaker 03 And in working on that startup, it really turned into this large orchestration problem. I was making millions of L L M calls to extract structured information from job descriptions that I was using to feed my recommendation engine. So I was a customer of Prefect, actually. I was doing orchestration of scraping job descriptions, doing orchestration of a lot of L L M calls. And so I was using Prefect a lot and was building a lot of internal like AI orchestration tools. So I built that on top of Prefect. And in 2023, Prefect put out like an L L M framework to help basically like do a lot of these sort of L L M call orchestration. And I loved it and it was almost exactly what I had built internally.
5:17 Speaker 03 And it's so rare that you find kindred spirits in how you like think about software and how to build it. And so I D M Jeremiah on Twitter and I say like, hey, I like the cut of your jib. Like, I like the way that you guys build software. Do you guys want to talk about this? And I think what started off as maybe a discussion about becoming a maintainer for that library quickly turned into, hey, do you want to build software together? And so I joined Prefect as an employee three years ago and really have just been working with Jeremiah super closely on how to make Prefect the best orchestrator for AI workflows. And then about a year and change ago, as Jeremiah mentioned, when we first saw M C P, it was funny because to us, we'd always been obsessing over like, all right,
6:01 Speaker 03 if a human is writing a workflow, how do we make this ergonomic and pleasant to go take this workflow and go execute it as the human had written it? And M C P was very interesting to us because it was, well, just programmatically you write this inner opera. Toolset and you can go hand it off for an agent to go figure out the right control flow to execute this stuff in. And so when we saw MCP, we thought it was a cool orchestration primitive. So that's what really got us interested. And when it first came out, it was a low level framework. So maybe for your listeners, like if you're in the Python world, they built Starlet is what they released. If you're in the JavaScript world, they put out Node. And we were kind of hungering for like, what's that fast API or that NextJS style experience? Like, one higher level order of abstraction that lets
6:46 Speaker 03 us kind of move fast and not break things. And so Jeremiah and I were going to get together that next week to go start on it. And fool me 10 times, shame on me, Jeremiah just disappeared over the weekend and showed up on Monday with fast MCP totally built out. And so shame on me. But it was very cool. And that's a bit of how I got involved in the project and maybe jumping the gun on kind of the genesis of how we got started on it.
7:09 Speaker 01 Amazing. Yeah, it's a really nice story in terms of how you guys got to working together. Sort of feels kind of like air quotes here, like old school, like where you actually just sort of cold email it sounds almost. And then like, just start working on something together. Or rather Jeremiah started working and then you caught up at him.
7:24 Speaker 03 Yeah, no, that's such an apt description of our relationship.
7:28 Speaker 02 I was gonna say, it's not the most fair characterization. Gregor, we should probably clarify slightly because I think it's a really common misperception people have because it's easy to do that fast MCP is actually not a company at all. It is just a project and hopefully an ecosystem, which we're super excited about. Could have been a company potentially in a different life, in a different world, but Prefect as a profitable software business, which we're really proud of. We had this opportunity to steward this thing without the outside pressures that that normally takes to sort of found a young company. And so it's been really exciting to also do that with that sort of independence in mind.
8:02 Speaker 01 Yeah, I think that's a really good call out. So yeah, in terms of me saying founders and co-founders and this kind of thing. Yeah, it's
8:08 Speaker 02 We're stewards.
8:08 Speaker 01 Yeah, stewards.
8:09 Speaker 02 We're maintainers.
8:10 Speaker 01 That's a very good way to put it. Yeah. So let's sort of just talk about like that V1 basically of fast MCP. And I believe it was actually adopted like within the official MCP SDK. So could you maybe just talk through that? Like, how did that kind of? Come to be. And then what does the journey then look like? Cause we're on to like V3 now, I believe. And just to kind of clarify, has Prefect always been part of the story there? Or yeah, just sort of understand.
8:36 Speaker 02 Well, I think that's part of why there's a little bit of misperception. Fast MCB starts out as a weekend project of mine, as a side project. And with the best of intentions to not infect Prefect, which has sort of an intense product culture and focus. I put it on my personal GitHub under J Lo and Fast MCP. And that's where it was a few months later when virality hit and it took off. And we moved it under the Prefect banner as part of the 3.0 release a few weeks ago. And I think that the optics of that probably led to some of the confusion about it being independent from Prefect, which it never was in an honest sense, because frankly, as a founder of Prefect, nothing I do is separate from Prefect. That just doesn't work that way. But it was also something that the optics of changing it is very difficult.
9:21 Speaker 02 Change management is hard, no matter how much GitHub does the redirect. And so we wanted to make sure that we did that at a moment when we had the attention to explain why it was moving. And so there would be no concern. But that brings us back to the beginning. MCP is in the world. I don't know. I have a conversation about it. Maybe this is a cool thing. I go to use it. And frankly, it was just really hard to use, not because I think it was poorly written, but because it was just a low level SDK. It was not designed to be the most ergonomic thing. It was designed to be the thing that let you actually work with this JSON RPC protocol. And I'm a person who loves high level abstractions. And so I became a little bit frustrated, to be honest with you, with how long it took me to build a basic server. That I ended up really spiking out a lot of Fast MCP that weekend to just serve my own needs.
10:05 Speaker 02 And then I open sourced it because why not? Let's see what the world says. And then I kind of forgot about it. Like I had other things on my mind that I needed to go deal with. And it was a couple of weeks later, I got a call from David Soriapara, who is the inventor of MCP over at Anthropic. And he says, this is really cool. I think this would be a great way for people to use MCP. Can we make this part of the official SDK? And so that was the coolest call that I've ever gotten in my life. And we said, absolutely. We made sure that the open source license permitted this and then worked with David to copy my code base into. The official SDK where it remains today. There will be finally a renaming of the official fast MCP object coming up soon. It's become a little confusing that there are two a year and a half later. But yeah, so off it goes into the official SDK. Super exciting for everyone.
10:50 Speaker 02 And I sort of thought that was that. I thought that was the end of that story and I got my contribution and that would be that. And what happened is in the spring, when OpenAI and Google announced that they were going to support the protocol and it sort of really took off and it's sort of maximum hype moment, I think. There was this influx of folks to my essentially dead repo where I said, please don't use this. Please go use the official SDK. And they were begging for essentially a high level application ecosystem. How do I do auth? How do I do composition? How do I do this, that and the other? Things that I don't think are ever going to have a home in the low level MCP SDKs for a variety of reasons. And so we really wanted to serve that.
11:31 Speaker 02 And we already had this fast MCP repo that whether we were maintaining or not was a queue lighting stars like crazy. And so we said, great, let's let fast MCP one be the server building low level toolkit that we put in the official SDK. And let's build a fast MCP two that has all of these higher level abstractions that people seem to be asking for. And so that was maybe April of 2025, almost a year ago now. And we built that like crazy and followed the hype train and then eventually found it necessary to release a three dot O just a month ago to sort of actually design the framework as opposing to letting the whims of the MCP world dictate its roadmap.
12:07 Speaker 01 Nice. And one of the sort of key things, I guess, that started on this high level abstraction, I believe, was this decorator pattern that was implemented like this at MCP dot tool. Was that kind of what you did over that weekend and it kind of went from there or like?
12:20 Speaker 02 That was fundamentally what we ship. If we boil it all down and are very reductionist, I wrote this decorator that was just useful. So the way the SDK still works, to be honest with you, if you don't use the decorator is you register a single handler. And the request comes in where somewhere in it, there's the name of the tool that's being called. And somewhere else in it are the arguments for that tool. And you write a single handler that. Basically, you have to write your own dispatch logic. And in Python, we have an idiom for this. We have decorator patterns for when you're trying to call a function in a different manner. Prefect popularized the use of decorators in our world in automation. We were sort of the first thing that we tried to do there was make it super easy to say, this function needs to be automated by this framework. We have a very similar thing here. This tool needs to be part of that MCP server.
13:03 Speaker 02 And so decorator just seemed like this incredibly natural way to do it. Fast MCP's name is homage to Fast API, which popularized exactly the same approach of this function needs to be an endpoint in my web server, right? And so we are trying to make this very idiomatic Python pattern that I think is very familiar to folks just available. And we could point out a lot of different aspects of that Fast MCP one, but I don't think any of them mattered nearly as much as this single decorator. I don't know, Adam, if you think there's any other surface area there. I think that was it.
13:33 Speaker 03 No, that was it. I mean, you know, we were trying to just make it feel Pythonic at the end of the day, which is just an analogy for like idiomatically Python. And for us, our design goal is like, if somebody knows Python and they're already using Python tools or like frameworks, should they be able to like get started with this pretty quickly? Should there be like an analogy between, all right, you did this thing in Fast API? You've been using that for a few years. And so when we saw MCP, we were like, all right, this is going to be hard to use for somebody who already knows Python. And so how do we make this feel slightly more part of that ethos? And it was, well, there's some pretty established patterns around this. And so, yeah, just shipping those decorators out of the box. I think we were surprised that that led to enough ergonomics to get people to be excited about it.
14:18 Speaker 03 But I think that was really the first shot over the bow.
14:21 Speaker 01 Nice. I guess so, jumping across the different versions, one through three, like just that growth story, like what did that look like to you in terms of? I think one of you mentioned earlier, like there was some kind of semi overnight change on terms of the trajectory of this, like what was around that?
14:38 Speaker 03 It was like not popular at all for a long time. Like I think from November 26th, I'm going to like just plus or minus a few days. From November 26th to like March, I don't think anybody cared. So.
14:53 Speaker 02 We cared.
14:54 Speaker 03 You know, if, sorry, we cared. Yeah, yeah. We cared and there were dozens of us that cared. And so when we got a, like a star on the repo or an issue, we'd be like, oh my God, somebody cares about this thing? That's great. But yeah, it was really in, I think, March is when Opening Eye and Microsoft came out and they were like, hey, I think we're going to support this. And then now suddenly it was like, okay, this is not just some toy protocol from Anthropic. This is going to be an industry standard. And I think when it became an industry standard, that's when folks were just trying to figure out like, all right, how do I stand this up? How do I start immediately building with this? And so I would say about March is when we started getting crushed by issues and also just seeing like
15:40 Speaker 03 the downloads go up into the right. It's funny, back then we would look at the downloads going up into the right and we were like, oh my God, this is amazing. And then you contrast it with it now and I think we're like 100x magnitude more than we were at the time. And I would say that like through that summer, summer of 2025 was a bit of a pretty healthy hype wave. And then I would say that fall is when we saw enterprise like actually choose to take a bet on this. And so that's when we saw like the Databricks MCP server, the Snowflake MCP server, MLflow adopted us. And so that's when I think we hit mainstream enterprise adoption as opposed to like enthusiast adoption over that summer.
16:23 Speaker 03 And so that's when things kind of skyrocketed in the fall. And then that's when I think we started having conversations over the holidays, Jeremiah and I, where we were like, all right, we've got a bunch of enterprises that are like, hey, I'm trying to adopt this pattern in a fast MCP. I don't quite know how to do this. And then that's when Jeremiah called me up and he says like, I've made a huge mistake. There's like a thousand things that I want to do, but so far all of the features that we added have kind of been incremental or bolted on and I need to like take a step back and redesign the guts of this thing because all these thousand things that these companies are asking for, they're actually relatively straightforward, but there needs to be like a central
17:03 Speaker 03 Design philosophy so that adding these things can be not just yet another bolted on feature. And so that's what led to three, but Jeremiah, I'm speaking your story here. That's how I've seen the trajectory. Is there anything on that where you'll remember it differently?
17:17 Speaker 02 It's been an intense feeling of needing to deliver something to a community that's demanding it, which I've been fortunate in my career over, gosh, almost 20 years now to be involved in a lot of popular open source products, never one that's been this popular before. And so when we talk about downloads are skyrocketing or stars are skyrocketing, that could mean five stars. In the beginning, it's just when you have a side project like this, you have your finger on the pulse of it. I still get an alert in real time on every single comment and issue and everything on that repo. Back then, if someone took the time to chat about it, like it was the greatest. Someone actually found my software and they liked it and what can I do to help them? Right? And so you really have your finger on the pulse of it.
17:59 Speaker 02 But the outpouring of interest, both in the spring of 25 and then in the winter of 25, that led to both fast MCB two and fast MCB three was so intense that I actually restructured my role at Prefect very slightly and I formally asked my team, including Adam, to help me create the space to be an engineer who needed to do some intense design work and sort of disappear for a moment while not doing the company wrong by being sort of an absentee CEO. And I deeply appreciate that my team made it possible for me to go do some of that work. And as Adam said, in fast MCB two, that was all about great. We put this server building toolkit that I ham-fisted together as a bunch of decorators into the world and people liked the ergonomics of it, but it was literally bolted on to an SDK.
18:44 Speaker 02 And now the demand is for, well, how do you put off into that? How do you compose these things? And we needed to build abstractions that could actually handle the complexity of the like applications that people were starting to build. And so fast MCB two introduced those application level things. And then we just built feature after feature after feature, as Adam said, all summer, all fall. We're just a new feature bolted on proxying a remote server bolted on turning in open API spec into an MCP server automatically, which is both the best and worst feature we ever built. That on and all of these became independent code paths, thousands of lines of code to deliver these features. Users didn't know that they saw a common interface to them. But a disproportionate amount of, I think, the engineering know how here was the fact that they were
19:26 Speaker 02 actually completely different stacks that then emerged in a commonplace. And so, yeah, we had stuff we really wanted to do like yesterday. As a matter of fact, we shipped code mode server side, which Adam built and it's phenomenal. And I think that if we hadn't have made some of the decisions to re-architect fast MCP three, anticipating some of this cool futuristic stuff in the MCP world, Adam probably would have written like 5,000, 10,000 lines of code just to implement this thing. And because of transforms, which is a new thing we have, it's one file, he slots it in, it just works everywhere. That's the sort of engineering we want to engage with.
19:58 Speaker 03 It's funny, I actually have the counterfactual on this one where there was like construction in the office where I normally work. And so like, basically to go build this thing, I had to go work off of whatever some random laptop I had at home. And it had a stale branch of fast MCP on it, like I didn't pull main. And so I was working on a 2 dot X branch and I'm working with Claude and I'm like, all right, here's roughly how I want the API to look. Here's what it should do. I'm going back and forth with it. And it comes back with this like plus 4,000 minus 2,000 change. And I messaged Jeremiah and I'm like, I thought this was going to be such a straightforward change. Like, I don't know what's going on. And then, of course, I like push it to a branch, there's
20:41 Speaker 03 merge conflicts. And then that's when I realized that like, oh, I built it on a 2 dot X branch. So then I go basically replay my whole session on a 3 dot X branch. And I think it, what did it end up being Jeremiah? Like, the tests are probably like 800 lines of code, but the core feature itself is probably like plus 500 minus 100. And so, yeah, I actually have the counterfactual here of just like, three definitely made it a lot easier to actually build these things at the end of the day. Not just more, you know, spaghetti tack on.
21:09 Speaker 02 I just looked it up and net of tests, you were plus 1200 and your tests were 500. So yeah, you got it down to a couple hundred lines of code. And that's why we built fast MCP three. And then we didn't plan this. I just looked it up right now, right? But like, that's why we built fast MCP three. So a feature like this. Which is transformative. We're going to, after we record this podcast, we have to go in the world and tell people about it. Just shipped last night, but this is transformative feature, in my opinion, and it was a couple hundred lines of code. And that's, if you can't innovate at that speed in this like AI crazy world, I don't know what you're doing. We had to create that opportunity for ourselves.
21:40 Speaker 01 Yeah. So we're going to get on to code mode and it's incredibly awesome that we're speaking to you the day after this thing was created. And as you say, you're going to go off and tell people and we're doing it in real time. So that's, that's cool. Let's just talk about just before that was a thing, kind of the, I guess, the sort of three pillars, if you like, of fast MCP. So basically on server, on client, and then the newest before code mode was on apps. So could you maybe just like walk us through those three, like, let's start with just the one that most people be most familiar with, which is on server.
22:12 Speaker 02 So servers is the meat and potatoes of fast MCP. It started, fast MCP one is literally how you build a server. Fast MCP two is how do you compose a bunch of servers into an application? And now it's really with fast MCP three that we're trying to take a much more opinionated framework approach to the entire ecosystem of MCP. And that's where we came up with these three pillars to organize our work, servers, clients and apps, because they have very different, well, very different use cases and very different users, and they all show up in this kitchen sink framework. And frankly, we just, Fesmce is getting very big. We need a way to organize it. And so this is just a very natural way that aligns on, I think, the big initiatives in the MCP space. So when we talk about servers, which is where we focus most of our time on fast MCP.
22:54 Speaker 02 What we're talking about is you, as the author of code, want to expose it to an agent. And the server category, I think, encompasses everything that could possibly fall in that with a big asterisk, because we're going to talk about apps in a moment. So maybe a better way to say that is you want to expose it directly to an agent. Apps will be how you expose it to a human. And what do you need to do? You need to authenticate, you need to authorize, you need to version, you need to maybe compartmentalize and build modular applications. You need dependencies, you need latency, you need middleware, you need transfer, it's all this stuff that it takes to get it in the world. Can we, as framework authors, come up with a sane set of common
23:33 Speaker 02 Defaults that let you ship a server as quickly as possible while still exposing all the knobs in the place you'd expect to see them on the control panel so that you can build your own. Fast MCP tries to expose as much of the configuration as possible, but it is not our goal. If you really want to build this thing from scratch in exactly the way that you want, then you really should be using the actual SDK. Fast MCP is not trying to funnel you to the SDK. We have an opinion represented in code about what the happy path is for the vast majority of use cases that we are fortunate enough to now see in the world. And that's what Fast MCP is. And so that server bucket really encompasses, I think, the vast majority of that capability.
24:16 Speaker 02 The client bucket is probably not what most people think. And Adam, maybe I'll turn it to you, although having said that, like weird cliffhanger, I won't leave it to you to fill that out. But what I mean by that is we're not trying to build an LLM client in Fast MCP. We're trying to make sure that you can interact with a server at all. So Adam, I don't know if you want to pick up there, maybe.
24:34 Speaker 03 Yeah. So if a server is really like, how do I write business logic that can be exposed over the wire to an LLM to call, right? So like a server, you can think about it as a big bundle of tools, data, slash commands, you know, that kind of stuff. It's a portable toolset. You can, if I take an MCP server and I author that business logic once, then the promise of MCP is that it can be used wherever MCP is accepted. So that's Claude in the web for maybe technical, non-technical folks to use, ChatGPT for non-technical folks, can be used in Claude code. It can be used in your favorite LLM framework. So clients then are really basically the means through which you can consume an MCP server.
25:16 Speaker 03 And clients, for every protocol rule about building a server, there's probably like, or for every five rules about building a server, there's one for a client. So like, clients tend to be very unopinionated, or there's not a lot of opinions about how you should build clients. What clients have to do at the end of the day is they have to connect to the server. They have to go peruse what tools are available and then represent that somehow to your base LLM client. And so there's a lot more design leeway in how people build clients that really impact the end user experience. I'll give you an example. In Claude Web, that's an example of they have an MCP client. And when I log on to like Claude's web client and I put in an MCP server,
26:01 Speaker 03 they will go and they will fetch every single tool. And on the first chat that you have with Claude in the web application, it will say like, Gregor, you'll be like, hey, what's the weather today? And every single MCP server that you have connected to, it will take all of those tools, all the different representations of them, all the arguments, keyword arguments, whatever. And then also go shove them behind the scenes into the context window of your LLM. That can maybe penalize or lobotomize whatever LLM that you're working with, because you're stuffing it full of context that it may not be relevant to it. There are other MCP clients like Claude Code, which now dynamically searches across your MCP catalog. So Claude Code, you can go stuff it full of a hundred thousand tools.
26:46 Speaker 03 And if you say like, hey, what's the weather, like all of us normally do with Claude Code, of course, instead of going and taking every single tool and putting into the context window, it'll actually do like, I think it's just BM twenty five search over all of your tools to go highlight like which tools are most relevant to this query. And so servers tend to, the business logic that you write, that is maybe like what informs the quality of a server. MCP clients tend to differ wildly in their design and quality. Because MCP clients, they don't have to support the full specification. Many of them only work with tools. Half of them work with resources, which is another part of the spec.
27:27 Speaker 03 Maybe another half work with prompts, maybe another half work with tasks. And so your mileage may vary with clients. And that's really where like, what I find are the distinguishing, that's actually really what drives my choice to use any one specific provider at the end of the day. Like whether it's Claude or ChatGPT or something like that. So that's clients. Clients are really like, they own the responsibility of talking to the server, understanding what Abilities are available and then choosing how to represent those tools to the base LLM at the end of the day. And then applications, maybe I'll tee up the first part and pass it back to you Jeremiah is like MCP apps at the end of the day.
28:07 Speaker 03 They're sort of born out of the following problem, which is Gregor, you and I are going to go build an MCP server that it's a search over like restaurants in New York City or like Northern Scotland or something like that. And Jeremiah gets into Claude Webb and he says like, hey, I'm going out to dinner in Northern Scotland tonight. Like, what are the best places for me to eat? And what Claude Webb is going to do is it's going to call our MCP server that you and I wrote. It's going to get a big like list of restaurants. And it's going to just render a long markdown list of like, great, here is the hundred restaurants that were returned to me from the server or something like that. And what MCP apps did is they said like, well, look, like we've got, I don't know, how long have we been making user interfaces like 40 years or something like this?
28:51 Speaker 03 It basically acknowledged that like, in the last 40 years, research did not conclude that markdown was the best way of presenting information to human beings. That there's better visuals, like maybe I actually want to see a photo of the thing that I'm trying to buy. That helps me make a decision. Maybe instead of seeing like the number of stars in markdown or seeing like a list of dishes they have in markdown. Maybe I want to give people the ability to like peruse through those photos or swipe on them or read reviews, that type of stuff. And so MCP apps kind of was born out of this. We've spent a lot of time figuring out that there are better ways of presenting information to humans to make a decision.
29:32 Speaker 03 So in an LLM client, restricting ourselves purely to text in and text out really limits the interactions that we can have with a system through an LLM. And so MCP apps were really born out of this, like, what if the server, instead of just sending text that your LLM will render as markdown? What if the server can send data and a representation of how to render it? And then the LLM client can take on the responsibility of rendering that in the way that the server is dictated. And so that's where basically you get a really, really cool design space that you didn't always have with MCP out of the box. Jeremiah, anything to add there?
30:13 Speaker 02 I think if it's interesting to the listeners, we can talk about sort of our unique take on this and where I think we can add some value as a framework, also in clients, right? So these are related. I'm just going to say like, most MCP clients are terrible. They implement tool calling and they are probably solely responsible for most of the legitimate charges that MCP has failed to reach its potentials because yeah, you are correct. Most clients can't do the majority of the things that MCP is intended to do. And that's a real problem. And so even testing is one of the reasons we introduced Fast MCP's own client. So we could just have good deterministic fast tests of our own servers. And so that's really an angle we're pushing on. I'm very concerned that apps, which I think are a phenomenal innovation for MCP, will also be left by the wayside by most
30:55 Speaker 02 clients. And so I think it's even worth shouting out a few of the ones we like the most. Goose is a phenomenal client. VS Code is a phenomenal MCP client. Claude Code is a phenomenal MCP client. MCP Jam is a phenomenal MCP client. There are probably others. I don't mean that's an inclusive list, but those are ones that I use regularly. And I use them because I can test the entire range of MCP and I can do cool things. And one of those cool things is build apps. Adam and I were chatting on our podcast, which compared to SE Daily is like a diggy next to an ocean liner. But nonetheless, we were shouting into the void about apps and talking about how it's a little dismaying that the first crop of MCP apps are basically SaaS applications stuffed into a chat window, right?
31:36 Speaker 03 And the promise of MCP was like, you don't have to go browse people's SaaS apps anymore. Like instead of 12 SaaS apps, you get everybody's SaaS data inside of one LLM client.
31:47 Speaker 02 I think it's good. It's useful for all the reasons Adam said, but is it really the promise of the user experience that we can deliver right here? And so when I think of where things break, and Fast MCP's roadmap is primarily defined by what is hard. Building services hard, we make decorators for that. Authenticating services hard, we make one-liners for that, right? Deploying services hard, we build a product for that. There's, everything is dictated by what's hard. What's really hard right now is working with large amounts of data, which is a world that we know intimately from Prefect and from our professional histories. If I go off and I run a SQL query or something against a database and I get 10,000 rows back. What are we supposed to do with that? Either that's going to be stuffed into my context window so the LLM can tell me about it, or we're going to have to now go write some summary of that,
32:30 Speaker 02 which is going to take time and latency and tokens and maybe not be what I want. What I really want when I make a query against a database and get so much information back is I want to probably either browse it myself or plot it, get an impression of it and go on and do that in an interactive way. And so that's the type of thing where I think MCP apps almost, I've been calling them mini apps. I don't know if that will survive as a vocabulary, but little discreet, interactive experiences that let me step around the context window and not pollute it with all this nonsense, but just let me access the result of something. So I think showing charts, showing data tables and showing forms, I expect to be something like 80, 90% of all of the MCP apps use cases
33:13 Speaker 02 because it exactly satisfies this idea of let's exchange information interactively between the MCP server and the user who's interacting with it. And let's not force the LLM's context window to be a part of that conversation. And so when I think about this, I'm a Pythonista, Python guy, whatever. I don't know what the term these days is. I love Python. I think it's a phenomenal language. Thanks to Claude, I probably can write in any language I want, but the language I know and have opinions on and know how to think about idiomatically is Python. And so when I think about the opportunity that there is to introduce these interactive applications as MCP apps, but then for obvious reasons, all of the weight and gravity there
33:55 Speaker 02 is in the JavaScript and TypeScript MCP SDK in particular. It made me wish that there was a way to do that in Python. That's a very dangerous wish, right? We are not trying to port front ends to Python. But the other thing that's been on my mind is generative UIs. So what if the agent just wants to show me something, but I haven't bothered to pre-program it as an MCP application? And so another late night conversation between Adam and myself led to the idea of a JSON protocol that itself could compile to a limited but highly functional React application. And now, all of a sudden, an LLM can write JSON, a human can write with a nice little Python DSL,
34:38 Speaker 02 and you can quickly compile these restricted but functional web applications. And so this is another thing that we have not really talked about publicly, except kind of cryptically. So I guess this is the first real time. But we've been building this in the open and, you know, folks have been kind of drive by and peering in and saying this is interesting.
34:53 Speaker 01 And it is interesting because, you know, like some of the cases, admittedly, I don't use MCP a whole ton. Just gonna put that out there, but that's not any shade against MCP. That's just purely my functioning professionally, et cetera. But when I am using LMs, which I do use a lot, and something vaguely complex has to be given back to me and in an interactive way, it then just becomes a entirely written React app. And I'm like, there must be a better way than an LM just going from scratch on a React. And I hit the stop button and say, no, no, no, no, you're not going to create a React app to show me this. I don't need that, like, but there has to be a better way.
35:29 Speaker 02 That's exactly it. And so my dream is that as an MCP author in Fast MCP, if I know that I'm getting a bunch of data back, I want to return a bar chart in the same way that I would return a dictionary or a PyDantic model or something like that. That's what we have been building. It's called Prefab, it's in the universe as an open source project. And it is a very simple DSL for building these interactive applications. And we're building a, you know, a native integration into Fast MCP so that you really can import the bar chart component and return it. You can import the data table and return it. You can build forms from PyDantic, you can do all this stuff. And the goal is, yeah, someone is using, say, the Superbase MCP server and they want information. Oh, 10,000 rows come back. The LLM can decide how to present it.
36:14 Speaker 02 The MCP author can decide how to present it.
36:18 Speaker 02 It's all possible and we don't need to go to a different ecosystem, which aside from just being different, which for someone like me is going to be a pretty big friction, a big hurdle to actually bundling an app. It also means that you have this weird tight coupling where how do I know that my app and my MCP server are in sync? What if I change the name of a tool on my MCP server? Do I have to remember to go to my other application now that's tightly coupled but independent? We don't like that. We want it to be one place, one happy path. And so we're trying to solve for that without re-implementing the front end world. And it's been, that's been a real adventure. That's probably one of the crazier projects I've ever worked on that has now really overspilled its bounds. And we'll really be talking about that a lot in a couple of weeks when it's. More ready than it is now, I guess.
36:57 Speaker 01 Let's talk about code mode then. So this ultra new flavor, like you're clearly very excited about it. So I want to hear more about it.
37:05 Speaker 03 So we talked earlier about like MCP clients and their relationship to servers, right? So an MCP client takes on the responsibility of getting all the capabilities that are available on the server and then choosing basically what to do with them. And the default for the longest time was go get all the tools, present them all to the LLM at the same time. This is where you get like context bloating that, you know, over the last few months. And then you also have this pernicious problem where the LLM will, if you pass it all those, those tools to an LLM, the LLM will invoke those tools serially. And so it'll call the server that you and I authored, it'll get restaurants in Northern Scotland. And then I'll say, okay, this, this restaurant looks great and it will go fetch reviews.
37:50 Speaker 03 And then after I say, okay, it's well reviewed, then it will go and it'll fetch the menu items. And then that's when we discover that like, you know, I, I don't like the food or something like this. But you'll notice that the LLM is invoking one tool after another. And if you take a step back and you think through like mechanically what's going on, it's, you know, you're taking a conversation up until, you know, end messages. You're invoking a tool, you're appending that, you're shoving that back over to your server, comes back. You append another tool, you shove that entire thing back over to the server. It means that, you know, unless you're managing caching yourselves, then you end up having this like quadratic number of tokens as you keep having a conversation, one message over another,
38:35 Speaker 03 and shoving it back to the server every time. And there were a couple of swings at how to solve this problem. So it starts off with, with the team at Block, who a few months ago, I think actually was one of the folks who pioneered this pattern of, well, if you've got like a thousand tools on the backend, you probably don't want to like just lobotomize your agent with a thousand tools. You should probably give it access to search and then you should give it access to execute. So instead of giving it a thousand tools, you give it a tool to search over your tool catalog. And so it's going to, you know, return the three tools that are most relevant. But where Block stopped is Block was like, great.
39:17 Speaker 03 And now you've got those three tools and then Claude will execute those tools one after another. The company who kind of said like, all right, hold my beer, like, I'm going to check raise this idea was Cloudflare. So Cloudflare came out and they said like, that's actually, I think Kenton Varda is his name. I might be butchering his name, but he basically, I mean, this is somebody who's been working on just like RPC for a while. And he was basically like, well, look, I'm glad that Block was able to like reduce context bloating with this search tool. But the idea that it still has to call tools one after another, that kind of seems goofy to me. Instead, the key observation that I think that team had was most L L M's are great at writing programs.
40:01 Speaker 03 So instead of forcing it to execute a program of call this thing, then pause, then call this thing, then pause. Why don't we give it the ability to author a program in the actual toolset that's been provided to it? And so what this means is that in code mode, you give your L L M client, you basically give it a search tool to search over entire catalog. And then you give it the ability to write basically a program in your M C P tools. And so what that program is going to look like, it's Cloudflare, so it's TypeScript on their end, where they're like, great. First, I'm going to in parallel, go get the top 100 restaurants in Northern Scotland. Then iterating over all of those, I'm going to go fetch their reviews and go fetch their menu.
40:46 Speaker 03 Then I'm going to take this data, then I'm going to go do something with it. And so if I wanted to go get 100 restaurants and then for each one of those restaurants, go and get their reviews and menus or whatever. In traditional M C P clients, you're, you're making hundreds of tool calls, which means you're making like, you know, N squared number of tokens you're submitting back and forth to the server. And so it's really, really cumbersome. And so they basically, on the client side, a few months ago, were like, great. So I'm going to show you in an M C P client how to, to author this so I can execute a program against the server. And it was a hit and it sparked a lot of discussion, but ultimately it was a client concern, which was tough. When something is a client concern, think about it from
41:31 Speaker 03 the perspective of an author.
41:33 Speaker 01 I've got to interject for one second. Listeners know me as living in Singapore, which I do, but I happen to be Northern Scotland when we're recording this. So that's why Adam keeps talking about Northern Scotland. As we would be talking about Singapore a lot, but we're talking about Northern Scotland, which I love, which I love.
41:46 Speaker 03 But that's why you need to know about the restaurants because you're, you're, you happen to be in Scotland.
41:49 Speaker 01 I don't have as much knowledge up here of the restaurant scene. So this is, keep rolling on it because it's, it's good, it's good.
41:54 Speaker 03 Okay, okay. But think about the experience of you and I writing this server. So like you and I, we both quit our jobs. You and I go write this like restaurant MCP server and we're going to stake it all on it. And then what happens is like, we start going and we share this thing. And the feedback that comes in is people say like, oh man, this is amazing. I use this in Claude and this was the best experience ever. And then somebody uses it in chat GPT and they're like, this MCP server sucks. Like I can't get it to do anything. And that's infuriating as a server author because you're implicitly depending on separate clients to all have the same behavior. And so CloudFlare had this great idea, which was, how do you let clients author programs against servers?
42:36 Speaker 03 But where it kind of failed to get adoption was like, all right, that's like, that's cool, but like, I'm never going to be able to get chat GPT to like, know that it has to write a program. I don't have access to that client. Like I can't go request that it operates in code mode. And so I think it was about three weeks ago that, you know, CloudFlare was like, well, why did we need this thing to happen on the client? And it was because, well, the client has its own secure runtime. And so it can author a program and we don't have to think about the security of like executing untrusted code. But as I'm,
43:17 Speaker 03 I'm sure folks listening know is like, there's also kind of been another separate renaissance in, let's call it AI infra, the last few months. And that's really been the, the focus on, let's call them like code sandboxes, remote sandbox execution. And so CloudFlare was like, well, look, we can actually take this thing that you had to be lucky if a client implemented it.
43:39 Speaker 03 And we can actually make it happen server side as long as that server is equipped with basically a secure primitive to go execute that that untrusted code. So CloudFlare has its own sandbox runtime, so it was also good advertisement for CloudFlare. But the real excitement from us came from is like, well, now you and I again, you know, we code our jobs, we build this server. Now what we can do is we can say, hey, on the server, I'm going to just expose two tools. I'm going to let people search over this giant catalog of tools behind the scenes. That's always existed. But now I'm going to let my clients submit code. And then I'm going to take on the burden of securely executing that code against all of my backend tools. And so that's code mode in a nutshell.
44:24 Speaker 03 Is code mode started as a client concern where you had to be very lucky and fortunate that you were using a client that could could support it. And then now where CloudFlare, I think, really pushed the envelope was saying like, well, you know, now that sandboxes are pretty good, we can actually, in a very low latency way, go and execute untrusted programs that are written in your MCP tools. And so, so last night, what we what we did is we basically shipped, you know, hey, in a line of code, like, you know, this MCP server that you used to ship that had like 300 tools on it, just enable this option. And what we'll do is we will expose it, a search tool over your catalog of tools,
45:05 Speaker 03 and we'll give you a means of executing code written by your your clients that connect to it. And so you can bring your own secure sandbox runtime. You can use Modal, Daytona, CloudFlare, like whoever you want. But what we ship with out of the gate is a secure local sandbox environment that was written by Pydantic. It's a new project of theirs called Monty. And so they basically allow you to, you know, a handful of microseconds, spin up a secure local runtime, basically like a sub-process but safe, like that's Samuel's going to kill me, that's not the right way of describing it. And so we finally, I think, have a really happy with what we got out, which is basically
45:49 Speaker 03 now your clients can submit programs over your MCP tools. You can spin up a local sandbox thread that executes that program and that little sandboxed thread. Only has access to those tools, so it can't go do funny stuff. You can make sure that it only has specific resources, no other connection to the internet. I mean, we've run a bunch of tests on it. We've run it in our own MCP server and it's been great. The downsides are when it's sideloaded against a bunch of other code mode servers. If the super base one is running in code mode and the prefect one is running in code mode, cloudflare is running in code mode. What does Claude see when it opens its eyes?
46:33 Speaker 03 It sees like, oh, should I call the search tool, the search tool, or the search tool? And should I call the execute tool, execute tool, or execute tool? And so like, there's still some namespace collisions. I'm sure that that'll evolve a little bit, but for a single server, it's definitely a huge improvement.
46:47 Speaker 01 Amazing. This will get released probably a couple of weeks after we've spoken, but this is available kind of now. Is that right? Or?
46:53 Speaker 02 That went out last night as we're recording this in SMC P3.1. And what I'm super happy about, aside from the fact that it works really well, is it makes the bet we made in the 3.0 rearchitecture. So visceral, I already mentioned that Adam's PR itself was small. But for example, one line of code, add code mode to your server. Two lines of code, add code mode to somebody else's server because we can proxy it so quickly. Three lines of code, add code mode to somebody else's server and customize the search tool because you know that they have a ton of tools and you need to like, that sort of progressive incremental complexity where you only need another line of code to add one more feature is what we're trying to achieve in building a really effective toolkit and framework.
47:35 Speaker 02 And so I'm just very happy with this as like a proof point of a lot of decisions we made over the last few months.
47:39 Speaker 01 Yeah. And as you said, Adam, I mean, like the sandboxing part, that's super interesting. And, you know, we're seeing a lot of players go the sandboxing route now. And well, Pydantic being kind of what, what was the name of the Pydantic's version?
47:53 Speaker 03 It's called called Monty.
47:55 Speaker 01 Monty, there we go. I had Sam on for an episode not that long ago. So yeah, go check that out, listeners, if you're interested to hear Sam talk about all things Pydantic AI. But yeah, Monty, great choice. So it's a nice segue, though, when we talk about sandboxing, because what is not sandboxing is OpenClaw. So I think this is perhaps what some of our listeners might be thinking now, and sort of as we go into our vaguely landing the plane phase of the episode, I want to just talk a little bit about OpenClaw. And I want to also just talk about MCP's current and future state when it comes to what some developers might be thinking right now. So let's just quickly touch on OpenClaw. What were your reactions? And did you ever look at that and think, oh, like, this is going to have
48:37 Speaker 01 an effect on sort of how MCP is viewed or anything like that? I'm just curious, like, because it had such an explosive landing in the for us as developers and even non-developers who come across it. But like, from your perspective, what did it look like and feel like?
48:51 Speaker 02 I love it. I think it's phenomenal. I've now deployed three iterations of my bot where I've slowly trusted it more and given it more capabilities. But I'm still a little, you're always a little nervous when you have something, something like this, right? But it's been an incredibly useful thing to me. I actually started as a, as a family focused bot, because I realized every company in the world is trying to sell me productivity software at Prefect. Nobody seems to be trying to sell me productivity at home. And I have a lot of kids, my wife and I both work full time, and there's a lot to do there. And so I actually started it just at home, managing, like, keeping an eye on my school calendar and what the kids need and else. And it's been phenomenal. And so I've been slowly
49:32 Speaker 02 trying to find a role for it at work. MCP shows up because we have to wonder, how do we give it new capabilities? And that's sort of the promise of MCP. Now, OpenClaw doesn't ship with a native MCP integration. Pete has a, has a tool called MC Porter, which is a tool that converts an MCP server into a CLI. FastMCP has a similar functionality. It's very useful in a lot of different cases. I think what it is proving out there for is the need for something like MCP, whether it is MCP or not, which is a weird thing to say. But something Adam and I spend a lot of time discussing in these arguments is Forget MCP. Let's just say that we want to add capabilities to an agent. Someone, somewhere, needs to define how those capabilities are accessed and what they look like.
50:17 Speaker 02 And if you want that to be a CLI, that's fantastic. Let's make it a CLI. So now I need human-written, natural-language help docs. I need a way to discover the commands. I need a way to discover the arguments. And before you know it, you end up inventing some sort of protocol for communicating this information upfront. Today, that protocol happens to be called MCP. And if you want to implement MCP via CLI, that's great. If you want to implement CLI without the MCP, that's great too. But do expect your agent to spend a lot of time discovering it. So my OpenClaw manages to kill itself about every hour because I ask it to do something.
50:50 Speaker 03 How bad is your calendar that it kills itself when it looks at it?
50:54 Speaker 02 What I'm trying to do is I'm trying to get it to install some new audio transcription software. And it keeps hallucinating a CLI argument, that there's an output directory. This just happens to be what I was struggling with this morning. And it keeps adding this into the OpenClaw config. And then it keeps restarting the gateway. And then it keeps killing itself because that doesn't exist. And it keeps making an illegal call. And so this is where I feel the pain of, oh, if only I had a tool that just broadcast exactly what was available and how to call it instead of having to write everything from scratch. Now, is that a reason to use MCP servers? No, MCP servers have other baggage that they bring, that they're not as easy to install, that they're not just written out as text, that they have to be hosted. There's all this stuff. So I'm not trying to make a strong argument that OpenClaw should or should not embrace MCP.
51:38 Speaker 02 But I am trying to make a very strong argument that no matter what the technology and the transport is, we will need a protocol by which people who write software and people who consume software, in this case, agents who consume software, agree on the contract of that software. What is the UI, so to speak, the AI, I guess, to use a bastardization of that initials, of using this software? And that's not going to sound as good to anybody. But MCP happens to be the prevalent way of doing it. And so what's been really fun is we're focused mostly on how you build the MCP servers. You want to deliver them as a CLI? By all means, go ahead. I think that's fantastic. I think it gives you, as a server author, a way to... Know for a fact that your software will be used with, you know, first try in the correct way.
52:21 Speaker 02 And it's our obligation to make that as easy as possible. And so I keep bolting new MCP servers onto my agent because it's easier to bolt someone else's hard work to build an effective server than have my agent write a wrapper script around a CLI to make it comply with what its expectations are. But I also use CLIs. I think at the end of the day, we're just trying to give our agents superpowers.
52:41 Speaker 01 And that's also a nice segue into, in terms of when we're recording, this was, this was one day ago, quite sort of high up on Hacker News was an article, when does MCP make sense versus CLI? Very timely. So rather than go through the whole thing, we're not here to dissect a Hacker News article, but at the end of that article, the person says, a plea to builders, it says, if you're a company investing in an MCP server, but you don't have an official CLI, stop and rethink what you're doing. Ship a good API, then ship a good CLI. The agents will figure it out. And I guess you've kind of semi answered that already, but I mean, I think it's just interesting to hear what you say to that.
53:20 Speaker 02 Adam and I have a hard one opinion that really affects how we view arguments like this, and it has to do with where MCP is being deployed. The vast majority of MCP use cases are inside companies for that company's own employees. The vast majority of MCP use cases that the average person is aware of are when companies release an MCP server for the use of their customers. We call that external MCP as opposed to internal MCP. If you are a company who is deploying an MCP server internally, you absolutely should not make it a CLI. You absolutely should make it an MCP server with a tight contract. You control the server, you control the client. You don't have to waste time building a client that knows your CLI. You get all the benefits of MCP and it's, and it's fantastic.
54:00 Speaker 02 And that's more than 80% of the use cases that we see every day. And at this point, fast MCP, I think it was downloaded like 2 million times just yesterday. Like we, we see the market. We know how people are using the software. With that said, I also understand that for the average person, they see MCP through the lens of a restaurant browser for Northern Scotland, and they may say, you know what? This MCP server could have been a CLI, and they may be right in that instance. And so this debate has taken on a very weird tenor where the median person doesn't see the median use case in a really interesting way, which I think there's probably some statistical paradox named for that, that I don't know, but I probably should. And as a result, we find ourselves arguing strenuously to companies to take advantage
54:44 Speaker 02 of all the contracts that MCP affords them for these internal use cases where we see, you know, if the long tail of MCP servers, I'm gonna say finger in the air, there's 20 or 30 MCP servers in the world that are popular, and then a long tail that have zero or one users. But inside a given company, some of the enterprises we work with, there are hundreds of MCP servers that are heavily used by only the, say, 5,000 employees of that enterprise. That's where we are focused on MCP as a primary and enabling technology, and all of these arguments sound ridiculous in that setting. And so I think it's a really complicated thing where I see these arguments, they make sense to me as a consumer. Give me the easier thing, give me the more flexible thing, just do the thing that is the most fungible, but inside an organization, I don't think that makes any sense.
55:29 Speaker 03 Yeah, maybe two things I'll add on this is just like, I think CLIs are probably a good MCP client, like if you squint your eyes, which is like, they can be good at consuming an MCP server at the end of the day. I think that a lot of the appreciation for CLIs is just that like MCP clients tend to be really bad. But if you go like actually introspect the tokens that are sent to the LLM at the end of the day, great, take a CLI, what's the first thing an LLM is gonna do? If it can even discover that it has that CLI available to it, it's gonna call like CLI- dash dash help. And what CLI dash dash help going to do? It's going to render all of the options that are available to it in its CLI.
56:13 Speaker 03 That's going to be more or less the same amount of tokens as rendering the list of tools that are available to it. That gets shipped over the wire. Then what happens next? Then it says, great, CLI super base create. I'm going to just whatever, or CLI restaurant finder find or something like that. Great, cool. And then what it's going to do is it's going to add an argument that's maybe of the wrong type. The server is going to reject it because you built that great API on the backend. You're going to get a 422 error also shoved into your your context window. That's going to say like, you formatted this this request wrong. And on the MCP side, you pay that tax upfront, depending on your client that says like, by the way, here's the JSON schema of like, how to format your data.
56:55 Speaker 03 So that the LLM has better type hints of the type of data that's going to be accepted by your backend server. And so like, I think that just empirically, the amount of you're like, I made a bunch of CLI requests and I had to guess at what the signature it is of the backing thing. That can be pretty tough. Or you go and you include all of that in your CLI anyway. And then you're just consuming just as many tokens. And so like, I find those kinds of arguments on like a token consumption business side kind of pretty unconvincing. I'd say the second bit, this kind of fits Jeremiah's picture of like inside of an organization is like, I'm not trying to be like a merchant of complexity here, but genuinely like,
57:38 Speaker 03 when I say the word governance, I don't mean like, you know, some bureaucrat sitting in a company that's like, trying to make up weird data rules. But genuinely, if I have an MCP server, there are going to be tools that can mutate and destroy data. And there's going to be some that can just read data. And even if you built like an API for your company, everybody can internalize the fact that like, Gregor, you should probably get read access on on prefix MCP server. Like if we give you access to it, you should probably get read access to data. You probably shouldn't get delete our internal data tools. And so what that means is that I have to have some backing server that looks one way when you access it, and it looks another way when Jeremiah access it. Jeremiah is my boss. So when Jeremiah sees that server, he should probably get some
58:23 Speaker 03 extra super special tools that I don't get access to. And so this idea of how do you get this many faced API? That represents itself one way to different people depending on their permissions. That's like a thing that's somewhat inexpressible through classic REST. The other bit of these MCP tends to to take on longer running tasks by virtue of just the types of things we're trying to get it to do. Which means that sending progress notifications tends to be a thing. The reason why I bring this up is great. We have REST APIs. Fantastic. Great. So we have REST. We want it to be stateful, identity aware, so it can reveal different interfaces to different people.
59:06 Speaker 03 It should be bidirectional so that I can give people progress updates on long running stuff. Okay, call an MCP or go implement that. You're like you're inventing a protocol either way. And so I think that I don't want to forgive the the sins of the the current state of MCP. I actually think it's it's pretty tame at the moment. I think there were some legitimate gripes over last summer. But maybe what I oppose to folks is just whether it's an API or CLI, like you want to represent different capabilities to different people. You don't want to have to give everybody API slash V two slash safe slash Gregor slash Scotland slash Singapore. V three final final. You want to just give them like superbase.com slash MCP or something like this.
59:50 Speaker 03 And once you commit to that as a design philosophy, which we can debate is a good philosophy or like a good design goal or not. Then to what Jeremiah said, all right, you either get MCP or you're inventing a new protocol. Or you're trying to get like hypermedia as the engine of all state, but trying to get people to adopt that and.
1:00:07 Speaker 02 You get into this place real fast. I like what you just said there, right? It's much more fun to debate the design of it than the implementation to transport of it. Like, that's ridiculous. And a lot of the critiques that you levy, they have solutions. A lot of them are solved by skills. And people also say, well, skills versus MCP. I'm like, no, skills with MCP. A skill helps you learn how to use a CLI. A skill helps you learn how to use an MCP server. Skill helps you decide if you even need an MCP. It's like, there's all this wonderful stuff in the ecosystem for enhancing the context of your LLM. I think at the end of the day, the most important thing is just do it in the way that the LLM understands. I think MCP is more LLM native than not, so I would do it with MCP. But they're powerful little creatures. They can figure it out. Maybe we can give them a hand.
1:00:53 Speaker 01 Yeah, well, I don't see a convincing argument because at the end of the day, it up to the developer to have figured out what they need. But there's clearly a massive use case for MCP.
1:01:03 Speaker 02 I think the thing we could agree on, like indisputably, is that you should always build a product for its user. That is one, probably the most true thing that I believe in my career is design the product for the user. CLIs are not designed for agents. So.
1:01:17 Speaker 03 Well, no, no, but CLIs are designed for like terminal agents and I think that that's fine, right? Like.
1:01:22 Speaker 02 Fair, fair, fair.
1:01:23 Speaker 03 Get ChatGPT to use your CL. Like if I went to ChatGPT and I was like, all right, go call the GitHub. Like now I'm depending on this one client to have a, a little VM that actually has any of these CLIs on it. And it's just like, I get it. If you're a developer, a CLI is a native thing for your Claude code client to, to call out to. I get that.
1:01:45 Speaker 01 So we're going to leave it there. I must make sure that my colleagues are happy with me. We're all in on MCP at Superbase and it's MCP.Superbase.com. So I will.
1:01:53 Speaker 03 Ah, that's sorry.
1:01:55 Speaker 01 Oh, you were so close. Yeah, yeah, yeah. But we're all in on it. And I know we've got users absolutely loving Superbase's MCP, but I'll stop plugging Superbase there.
1:02:03 Speaker 03 I really enjoyed collaboration with Superbase on launching the, while we're doing a Superbase commercial, the 2.1 OAT support.
1:02:10 Speaker 01 Yes.
1:02:10 Speaker 03 That was huge.
1:02:11 Speaker 01 Yeah.
1:02:11 Speaker 03 Yeah.
1:02:11 Speaker 01 Yeah.
1:02:11 Speaker 03 Yeah. That was a fun collaboration.
1:02:13 Speaker 01 And as I was, we were talking off audio before the episode, I discovered you guys in our Slack, which is always fun when you're about to speak to someone and then, and then a colleague says, oh, you know, go over to this channel. They're all in there, which is always, I love that about Slack that you kind of have all these intermingling or company to company. But I digress. Fortunately, we do have to wrap up. There's so much more we could have talked about, but as is always the way. In terms of classic kind of where to go up and running and also just contributing, do you have like quite a large contributing community or what does that look like?
1:02:46 Speaker 02 We do. I'm really proud. I think we have 200 individuals have contributed to the Fast MCP codebase at this point. Another eight joined the ranks last night in the 3.1 release. It's just, it's really cool to see. Anyone who wants to get involved, we do welcome it. The repo is at github.com/prefecthq/fastmcpe. That's where you can find us. I already mentioned, I think in this conversation, I get a notification on everything. I can't quite keep up the early prefect 15 minute response SLA, but I do do my best and would love to collaborate with folks to make the framework as great as possible. Docs are at gofastmcpe.com. You can find Adam and myself probably on your favorite social network, wherever that might be, and [email protected] .
1:03:29 Speaker 01 Amazing. Well, Jemiah, Adam, thank you so much. We've heard tons today. And yeah, this has just been a really fun one. Always fun to have two guests, not just one. So yeah, thanks for coming on and I'm sure we'll be catching up again in the future.
1:03:44 Speaker 02 Thank you so much for having us.
1:03:45 Speaker 03 Thanks for having us. See you in Singapore.
1:03:47 Speaker 01 Yes, yes.
1:03:49 Speaker 03 Cheers.
Previous SED News: OpenCode, AI Code vs. Shipped Code, and the LiteLLM Breach Next Mobile App Security with Ryan Lloyd Page updated November 6, 2026 · transcript and summary are machine-generated